OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

humanmarkup-comment message

[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