W3C home > Mailing lists > Public > uri@w3.org > January 2002

Re: Content-Location is your friend

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Fri, 18 Jan 2002 16:59:26 +0200
To: ext Mark Baker <distobj@acm.org>
CC: URN <urn-ietf@lists.netsol.com>, URI <uri@w3.org>
Message-ID: <B86E04EE.BD37%patrick.stickler@nokia.com>
On 2002-01-18 16:04, "ext Mark Baker" <distobj@acm.org> wrote:

>> The whole point IMO of URI schemes is to be able to capture
>> the common semantics and intended application of sets of
>> identifiers in a consistent and efficient manner.
> 
> That's true, but it doesn't mean that the only way to communicate that
> sort of information is with a new URI scheme.  The most general model
> would be to assume an opaque URI scheme, and then build up from there,
> no?
> 
> What should one do when they need to make these same kinds of assertions
> about an existing URI scheme that doesn't already support them (perhaps
> because it's opaque)?  For example, what if the owner of example.org
> wants to assert that http://example.org/foo/bar implies the existence of
> http://example.org/foo and http://example.org/?

But it does. Although it is rather implicit IMO in the definition
of hierarchical URIs, the individual path components are distinct
and hence can be referenced individually.

Note that that does *not* mean that subpaths correlate to URIs,
and this is the case also with 'hrn:' and 'voc:', only that one
can deduce that such subpaths might be valid URIs and in the case
of 'hrn:' and 'voc:' *if* they correlate to resources, there is
a defined superordinate/subordinate relation.

Obviously, though, it is difficult to rebake a cake, and if you
put the wrong ingredients into it...  cest la vie...  ;-)

Cheers,

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com
Received on Friday, 18 January 2002 09:58:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:30 GMT