Re: Content-Location is your friend

On 2002-01-17 19:28, "ext Mark Baker" <distobj@acm.org> wrote:

> Patrick,
> 
>> The "use 'http:' URLs for everything' approach suggests
>> that a given URL can be used both to denote the thing
>> (the car) as well as be dereferenced to retrieve a
>> representation of that thing (e.g. a photo, or technical
>> specs, etc.) 
> 
> Right.
> 
>> Yet, a SW application which is trying to "understand"
>> a given statement such as
>> 
>>    <rdf:Description rdf:about="http://foo.com/freds_car/">
>>       <dc:creator>Fred</dc:creator>
>>    </rdf:Description>
>> 
>> cannot tell whether Fred is the creator of the car itself
>> or of the digital resource retrievable from the URL.
> 
> That's not true.  We've had this discussion before, and I've pointed
> out that your assertion above is about the *resource*, i.e. the car.
> If a particular representation of the car was created by somebody else,
> then that should be reflected in a different URI,

I agree that if separate URIs are used to denote the non-digital
resource and digital representations/expressions of that resource
that what you say is true (though the argument that I was contesting
about "multipurposed" URIs seems to be a common one).

However, using a URL to denote a non-digital resource is IMO just
plain bad practice. The point of the 'http:' URI scheme (and forgive
me for telling all you other folks what that is, even those of
you involved in writing the RFCs ;-) is to provide a URI that is
meaningful to HTTP resolution, and HTTP resolution is intended
to provide access to digital resources.

The problem is that folks needing to talk about non-digital resources
have been so 'http:' URL saturated that they started using them
out of habit, or (fairly enough) not having much else to use, and
then IMO folks started trying to re-define what URLs are for in
order to justify this (mis)use.

The distinction between URIs denoting accessible digital resources
and URIs denoting either abstract concepts or non-digital resources
is IMO crucial for the future of the SW. Again, it may not be
crucial for the Web, but it is for the SW.

> and the relationship
> between http://foo.com/freds_car/ and this other URI should be
> authoritatively established with HTTP's Content-Location header.

A content header is not a digital-resource, it is part of the
interchange protocol which describes to the recieving application
what the content is -- how can you describe empty content?

And this approach presumes that all that can be known about
such a resource can be expressed in the content header. And it
requires the explicit definition of "non-dereferencable" status
for *every* such URI rather than globally for all instances of
a particular URI scheme, or ideally for a URI class such as URP.

Far better to be able to know that one has a URP and thereby
know that the URI is non-dereferencable than have to define for
*every* URP in existence an explicit header response. Yikes!
What a massive overhead!

This content header approach feels to me like a hack. Sorry.

Regards,

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 01:31:06 UTC