Re: [metadataInURI-31] A guide to where we stand on issue metadataInURI-31

On 2006/02/24, at 6:28 PM, wrote:
>> [nit] I'd rephrase this slightly to reflect that URIs *always* encode
>> metadata for private purposes (e.g., where to find the file / what
>> code to dispatch to).
> I think that's a bit strong.  Consider a uuid: scheme URI.  I would  
> say
> that it encodes metadata for private purpose only in the sense that  
> you
> can tell the scheme name, and you can do literal equality testing  
> to see
> whether two strings are the same URI.  Except in that rather sterile
> sense, I claim it encodes no "metadata for private purposes" (You  
> could in
> many cases crack the UUID to get a MAC address, but for practical  
> purposes
> they are treated as opaque.)  So, I think "always" is too strong, and
> interestingly so.

Ah, good point. I wasn't considering pure identifiers. I do wonder  
how common they are in practice (despite URNs ;)

>> I think that it's just as important to make this point (i.e., on
>> equal standing with those you put forth): "Authorities MAY
>> communicate information about the structure of their URIs (in other
>> words, instructions of how to extract metadata from them) for use by
>> observers."
>> Doing so is very useful and common, and people reading the opacity
>> documentation often conflate it with unhinted inference (which *is*
>> bad).
> I agree, though with the caveat that any consuming software the  
> depends on
> knowledge of such structure is likely to be less general than software
> that either treats URIs as opaque, or that extracts only metadata  
> covered
> by very widely deployed specs (e.g. extracting the scheme or hiearchy
> based on RFC 3986).

Yes. However, people are getting interested in Web description[1],  
content labels[2], and site metadata[3], all of which may provide a  
means for generic software to infer site- and resource-specific (as  
opposed to scheme-specific) metadata from URIs.



Mark Nottingham

Received on Monday, 27 March 2006 21:40:11 UTC