Re: Content-Location is your friend

On 2002-01-18 18:16, "ext Mark Baker" <distobj@acm.org> wrote:

>>> 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.
> 
> They can be referenced, but so can any local path.  That's not the same
> as asserting that they actually identify a resource.
> 
> Hierarchical naming does not in general imply the existence of resources
> elsewhere in that same hierarchy.  If you think you've found some text
> to the contrary, I'd appreciate a pointer though, as I've been looking
> into the opacity qualities of RFC 2396 recently.

I agree. And never stated that such was the case.
 
> The point here being that this assertion should be able to be made about
> any URI, not just ones using a particular URI scheme.  So the most
> general model for this would be entirely opaque URIs, and explicit
> assertions made about them.
> 
>> 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.
> 
> Sorry, I don't follow.

Meaning exactly your argument above, that just because a hierarchical
URI can be parsed into discrete subpaths doesn't mean that any of
the subpaths denote a resource -- but if they do, there is additional
semantics that can be inferred for an 'hrn:' and 'voc:' subpath that
cannot be inferred for an 'http:' subpath (or any other hierarchical
scheme I am aware of).

Thus, there is functionality defined for 'hrn:'s and 'voc:'s that
is not present in 'http:'s, all else being equal (which it isn't ;-)

>> Obviously, though, it is difficult to rebake a cake, and if you
>> put the wrong ingredients into it...  cest la vie...  ;-)
> 
> That sounds like it would be funny, if I understood the context.
> 8-)

Meaning that if needed semantics are not defined for a given
URI scheme from the get go, you can't (at least not easily)
go back and add it. That's why alot of thought went into the
recipes for 'hrn:' and 'voc:' ;-)

(though they may still end up tasting bad to some folks ;-)

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 11:46:44 UTC