Re: [metadataInURI-31] New editors draft for Metadata In URIs Finding

On Fri, 2006-05-12 at 13:30 +0200, Robin Berjon wrote:
[...]
> I find this foray into "URIs are cooler when humans can actually  
> fiddle with them (at their own risk)" to be highly encouraging. I  
> think however that it is incomplete without an adjacent discussion of  
> when and why it may (or may not) be appropriate to take active steps  
> in preventing users from being able to "explore and experiment" with  
> URIs, notably through such devices as including the creation year in  
> the URI (aka datedspace).

Could you elaborate a bit? I'm not sure I see where you're headed.

It seems to me that the argument against the year-of-creation idiom
is mostly covered by the example with
http://example.org/123Hx67v4gZ5234Bq5rZ

and the Good Practice Note: "URIs intended for direct use by
people should be easy to understand, and should be suggestive of
the resource actually named."

W3C basically has only a handful of URIs intended for direct
use by people: http://www.w3.org/ is definitely one.
I remember an explicit effort to get w3.org/PICS (aka
http://www.w3.org/PICS/ ) to work. Otherwise, our URIs are
chosen primarily to avoid broken links, which is explained
in the finding around the Good Practice note
"Resource metadata that will change SHOULD NOT be encoded in a URI."


> I wonder if a discussion of metadata in URIs that are not necessarily  
> dereferenceable (e.g. namespaces) could be useful.

The case of a namespace URI that is not dereferenceable is a bug,
according to webarch
(http://www.w3.org/TR/2004/REC-webarch-20041215/#pr-namespace-documents )
so I doubt such a discussion would be useful.

>  One aspect of this  
> is including the version number of the vocabulary in the URI.

I wonder if it's better to cover that here or in the versioning
finding. Perhaps a cross-reference is in order.

See section 8 of Dave's draft in progress.

8 Version Identification Strategies
    8.1 Version Strategy: all components in new namespace(s) for each
version (#1)
    8.2 Version Strategy: all new components in new namespace(s) for
each compatible version (#2)
    8.3 Version Strategy: all new components in new or existing
namespace(s) for each compatible

http://lists.w3.org/Archives/Public/www-tag/2004Nov/att-0071/versioning-part1.html

>  Another  
> is related to the above "hackability" of URIs but in a lesser form,  
> that is how hard should it be to remember a namespace URI, notably in  
> the context of an organisation that produces a great many of them,  
> and which authors will need to manipulate on a daily basis.

Are you suggesting that W3C should choose namespace URIs that
are easier to remember and type? I'm comfortable treating them
as opaque strings for the computer to manipulate, but I have
some sympathy for that position. There have been internal
discussions of something like http://www.w3.org/ns/mylang or
even http://w3.org/ns/mylang .
Those discussions haven't reached a critical mass, partly
because while nobody really loves the /YYYY/MM/foo idiom,
everybody can live with it and the politics of it are
relatively straightforward, in contrast with, say, the ICANN
process for managing TLDs and such.

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Friday, 12 May 2006 14:16:47 UTC