[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: A Library of Taxonomies [was Brass Tacks #2]
> I am afraid URNs will not be of any real use to us, [...] Really? XML is built on namespaces... they require persistent URIs. RDF is built on nothing but URI references, and they also need to be persistent. Having this URN space is very useful indeed, and many thanks to Karl for pointing it out. The identifers are, however, a little bit long. I was thinking of registering a top level "huml" or "HumanML" namespace, but now that we have this... the length is a mere inconvenience. > at least for some time [...] I agree with that. Well, in that we won't actually be *using* the URNs for quite a while, but if I'm hacking around with some code, it would be nice to be able to have the URN space to play around in. I presume it will be date stamped. Ranjeeth, can you set up a delagation policy for the URN space (if you have the power to)? That is quite important. A persistence policy etc. would also be useful. > (I also think that was also Sean's point, the inability of > URNs to serve our purpose). I'm kinda divided about URNs at the moment, in that I don't feel that the "urn:" prefix serves any quantitative purpose. I've been discussing this on uri@w3.org recently, and even the "URI experts" disagree on this. There are many subtleties to the debate, and I won't bore you all with them here. Needless to say, URNs will indeed be fit for our purpose, because they are simply URIs. My retort at Kurt's URN was that he started it with "urn://" and URNs are strictly non-hierarchial. The thought of a hierarchial URN is what made me laugh :-) > The taxonomy framework will make use of real URLs, [...] So a URN isn't a "real" URL? O.K., a URN obviously isn't a URL in a classical sense, but in a contemporary fashion, the boundaries between name and address are vanishing. URNs can actually resolve to network entities. I think, however, that using URLs is a fair idea in general, and there are many on the RDF lists that disagree with me. I have debate after debate on the RDF lists about URIs, what they identify, whether or not URLs can be used to identify names, whether or not URNs should be used to identify netwok entities, trying to get people to realise the difference between a resource, and the representation of that resource, and so on. > possibly even utilising RDDL, [...] Fine. [...] > Thus, this should require more flexibility in the choice of "paths", > and easy/direct control from the list developers themselves, > something that can be really possible only by utilising the > HumanMarkup.org domain at this point. > > But of course, there may be other solutions too? Well, I certainly don't think that we should use the HumanMarkup.org domain, unless we have to, for persistence reasons. Some of the URIs used on there already are absolutely terrible; some even have ".asp" file extensions, and no date-stamping at all. I contend that whoever's managing the HumanMarkup URI spaces (whether URL or URN) start doing their job properly :-) Well, it's not that bad, but it's not how I would have organized it [and I'm not great at URI organization either]. As far as persistence for HumanMarkup.org goes... how long is the domain registered for? Will it always be re-registered? Can someone point me to the HumanMarkup.org persistence policy? We're not a library, and neither is OASIS. Perhaps we can get a top-level PURL [1] or something? [1] http://purl.org/ -- Kindest Regards, Sean B. Palmer @prefix : <http://webns.net/roughterms/> . :Sean :hasHomepage <http://purl.org/net/sbp/> .
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC