Re: CoIN: Composition of Identifier Names

Hi Robert,

On 13 Apr 2010, at 17:11, Robert Sanderson wrote:
>> I've found it very valuable to formally declare the pieces from which
>> an URI is to be composed of. Especially in our environment where we
>> have a central design of the URI:s, but decentralized publishing of
>> data (which is of a somewhat rich and varied nature).
>
> How does this mesh with URIs being opaque?

The “URI opacity” axiom does not say that URIs should be opaque.

It says that clients should *treat them* as opaque.

This is because URI owners should have full authority about what their  
URIs identify and resolve to, and if clients make assumptions about  
what a URI will resolve to, then they are contesting this authority.

URI opacity in no way precludes URI owners from telling the world  
about the structure of their URI space.

In some sense, CoIN is no different from an HTML form that has  
@method="GET" -- it specifies a mapping from some data (in the one  
case RDF resource descriptions, in the other key-value pairs of form  
fields and form values) to URIs.

It is true that link following should be preferred over URI  
construction, but this is not always possible, as shown by the example  
of, say, HTML search forms.

(Examples for violations of URI opacity: the /favicon.ico convention  
-- suddenly, server operators don't “own” that URI any more, because  
browsers will try to fetch a web site icon from there, no matter what  
the server operator wants that URI to denote. Or assuming that all  
URIs that end in .png must be rendered as image files -- the publisher  
might have a web page at that URI, and the assumption conflicts with  
that.)

Best,
Richard


> If the URIs were actually
> opaque and treated as such, then formally declaring the parts would be
> a non-issue.  It seems that this ideal is being increasingly watered
> down or ignored... is that intentional, and is it a good or bad thing?
>
> Thoughts?
>
> Rob Sanderson
>

Received on Tuesday, 13 April 2010 17:28:22 UTC