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

Re: CoIN: Composition of Identifier Names

From: Ivan Žužak <izuzak@gmail.com>
Date: Tue, 13 Apr 2010 20:52:22 +0200
Message-ID: <x2u1b4ff0311004131152i92eb56f3xf932e36016824ed4@mail.gmail.com>
To: Richard Cyganiak <richard@cyganiak.de>, Pierre-Antoine Champin <swlists-040405@champin.net>, Robert Sanderson <azaroth42@gmail.com>, Niklas Lindström <lindstream@gmail.com>, Linked Data community <public-lod@w3.org>
Hi all,

Here's the juice on URI opacity, right from Roy [1].

The important bits:

""Opacity of URI" only applies to clients and, even then, only to
those parts of the URI that are not defined by relevant standards.
Origin servers, for example, have the choice of interpreting a
URI as being opaque or as a structure that defines how the server
maps the URI to a representation of the resource. Cool URIs will
often make a transition from being originally interpreted as
structure by the server and then later treated as an opaque
string (perhaps because the server implementation has changed
and the owner wants the old URI to persist). The server can make
that transition because clients are required to act like they
are ignorant of the server-private structure.

Clients are allowed to treat a URI as being structured
if that structure is defined by standard (e.g., scheme and
authority in "http") or if the server tells the client how its
URI is structured. For example, both GET-based FORM actions and
server-side image map processing compose the URI from a
server-provided base and a user-supplied suffix constructed
according to an algorithm defined by a standard media type."


[1] http://tech.groups.yahoo.com/group/rest-discuss/message/5369

On Tue, Apr 13, 2010 at 19:30, Richard Cyganiak <richard@cyganiak.de> wrote:
> 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 18:53:25 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:16:05 UTC