RE: The URI of a RDDL "nature"

Hello Norm,

I'm just catching up on this thread...

> It is with this in mind that the TAG wonders if you'd be 
> willing to establish new URIs with the pattern 
> http://www.rddl.org/natures#<term>
> for the natures. I would suggest preserving, but deprecating, 
> the natures listed above (so that there would be two natures for those
> resources) and simply dropping the rest. 

Under this proposal, RDDL natures become a closed space under the
control of the maintainer/owner of rddl.org rather than an openly
extensible space where anyone could contribute a new nature. Is that
really what the TAG wants?

It strikes me that one would want the space of rddl natures to be openly
extensible so that one could say something like:

	:myNatureTerm a rddl:nature .

in order to declare term as a rddl nature. Once could of course the
dereference the nature term to find more (machine/human) readable
documentation about that nature (maybe in another namespace document
:-).

Cheers

Stuart
--

> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] 
> On Behalf Of Norman Walsh
> Sent: 13 January 2006 20:10
> To: Jonathan Borden
> Cc: www-tag@w3.org
> Subject: The URI of a RDDL "nature"
> 
> Hi Jonathan,
> 
> If you saw the minutes of the last couple of TAG meetings, 
> you may have noticed that there's been some expression of 
> discomfort about the "nature" URIs in RDDL. Unlike the 
> "purpose" URIs which are all identified by anchors in 
> http://www.rddl.org/purposes, the nature URIs are drawn from 
> a variety of sources.
> 
> As you already observed, the use of "http://www.iso.ch/" as 
> the nature of an ISO standard is controversial for a few 
> reasons. The most technic argument against it, I think, is 
> that it conflates "a website"
> and "a nature" so that any descriptive statement made about a 
> nature must (by virtue of the use of the same URI) also be a 
> statement about the website. To a greater or lesser extent, 
> the same argument applies to several other nature URIs as well.
> 
> On the whole, I've been persuaded by the arguements and I 
> think it would have been less controversial if the nature 
> URIs had all followed the same pattern as the purpose URIs 
> (as several already do).
> 
> In approaching namespaceDocument-8, the TAG has been very 
> conscious of the problem associated with changing URIs that 
> are already used in deployed software. But it occurred to me 
> that very few of the "nature"
> URIs are likely to actually be used in deployed *software* *today*.
> 
> I would hazard that only the following are actually used:
> 
> http://www.w3.org/2001/XMLSchema
> http://www.w3.org/2000/01/rdf-schema#
> http://www.xml.gr.jp/xmlns/relaxCore
> http://www.xml.gr.jp/xmlns/relaxNamespace
> http://www.ascc.net/xml/schematron
> http://www.isi.edu/in-notes/iana/assignments/media-types/text/css
> http://www.isi.edu/in-notes/iana/assignments/media-types/appli
> cation/xml-dtd
> 
> And of those, only the first is really used by most implementations.
> 
> It is with this in mind that the TAG wonders if you'd be 
> willing to establish new URIs with the pattern 
> http://www.rddl.org/natures#<term>
> for the natures. I would suggest preserving, but deprecating, 
> the natures listed above (so that there would be two natures for those
> resources) and simply dropping the rest.
> 
> Note that this doesn't make www.rddl.org the gatekeeper for 
> new natures any more than it does for new purposes.
> 
>                                         Be seeing you,
>                                           norm
> 
> --
> Norman.Walsh@Sun.COM / XML Standards Architect / Sun 
> Microsystems, Inc.
> NOTICE: This email message is for the sole use of the intended
> recipient(s) and may contain confidential and privileged information.
> Any unauthorized review, use, disclosure or distribution is 
> prohibited.
> If you are not the intended recipient, please contact the 
> sender by reply email and destroy all copies of the original message.
>

Received on Wednesday, 18 January 2006 09:48:29 UTC