W3C home > Mailing lists > Public > public-lod@w3.org > April 2010

Re: CoIN: Composition of Identifier Names

From: Richard Cyganiak <richard@cyganiak.de>
Date: Tue, 13 Apr 2010 18:30:21 +0100
Cc: Robert Sanderson <azaroth42@gmail.com>, Niklas Lindström <lindstream@gmail.com>, Linked Data community <public-lod@w3.org>
Message-Id: <40662047-1D0D-4AA9-9093-BD79878C73BE@cyganiak.de>
To: Pierre-Antoine Champin <swlists-040405@champin.net>
On 13 Apr 2010, at 18:04, Pierre-Antoine Champin wrote:
> 2/ Given a URI, a software should not try to reverse-engineer it.
> However, the axiom does not prevent that a software be given a  
> *rule* to
> *produce* new URIs.
>
> As a matter of fact, I would be surprised that TBL would discourage  
> this
> very mechanism which underlies all HTML-based forms (at least those
> using the GET method). A form is nothing else than the specification  
> of
> a *whole set* of URIs, plus the technical tool to produce them  
> easily in
> your browser.

Didn't read this before writing my own response -- well said!

Cheers,
Richard


>
>
>  pa
>
> [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
> [2] http://www.w3.org/DesignIssues/Axioms.html#opaque
>
> On 13/04/2010 17:11, Robert Sanderson wrote:
>> A quick question...
>>
>> 2010/4/13 Niklas Lindström <lindstream@gmail.com>:
>>
>>> 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?  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:30:56 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:26 UTC