Re: HTTP Range Middle ground?

Paul Prescod wrote:

> 
> Norman Walsh wrote:
> 
>> ...
>>
>> Some people (I won't attempt to put words in your mouth) respond to
>> this by saying that the machines won't be able to tell. But machines 
>> can't
>> tell anything. I've lost the focus about why disambiguating
>>
>>   <http://www.tbray.org/ongoing/misc/Tim> rdf:type ex:Person .
>>   <http://www.tbray.org/ongoing/misc/Tim> rdf:type ex:WebPage .
>>

> The first two statements are not meant to be in contradiction. If you
> throw out the first statement then the resource is useless as a Person
> (presumably the whole point of the URI). If you throw out the second
> statement then the SW agent must discard the fact that the URI can be
> dereferenced. But more important, the agent must discard statements
> about the resource that only apply to WebPages, not persons, like
> statements about available MIME types or reliability.

Your assertion beginning "If you throw out the second statement..." 
isn't true, I don't think.  Whether or not you can get a representation 
is orthogonal to what kind of thing it is; this is true even for pure 
good old fashioned information objects.  The other issue you highlight 
"But more important..." is real, but only requires that you have 
different URIs for talking about the resource and some particular 
representation.

Which you suggest, but I don't think a URI-syntax convention is called 
for.  Because there are a lot of other properties we're going to care 
about, not just ex:WebPage or not, and we can hardly encode them all in 
the URI. -Tim




> 
> If we throw out neither statement then we must state the set of Persons
> and WebPages is not disjoint. But your common sense said that they were
> disjoint (like Peacocks and GardenSlugs).
> 
> I propose that the Semantic Web world merely say that it is a BAD
> PRACTICE to assert that HTTP URIs are anything other than "HTTP
> Resources" because it becomes impossible to make assertions about them
> AS HTTP resources without ambiguity.
> 
> At the same time, the TAG could invent some particular syntax whereby
> one URI could be said to represent the HTTP responder for another URI
> and vice versa. Then we could say that:
> 
> <http://www.tbray.org/ongoing/misc/Tim> rdf:type ex:Person .
> <http://www.tbray.org/ongoing/misc/Tim/resp> rdf:type ex:WebPage.
> 
> <http://www.tbray.org/ongoing/misc/Tim/resp> tag:responderResourceFor
> <http://www.tbray.org/ongoing/misc/Tim>.
> 
> But a better (less confusing) way of handling the same situation would be:
> 
> <http://www.tbray.org/ongoing/misc/Tim> rdf:type ex:WebPage .
> <http://www.tbray.org/ongoing/misc/Tim#Tim> rdf:type ex:Person.
> 
> <http://www.tbray.org/ongoing/misc/Tim> tag:responderResourceFor
> <http://www.tbray.org/ongoing/misc/Tim#Tim>.
> 
> If neither statement is present, then we use the current SW default
> which is that the base HTTP URI is the responder URI for a resource with
> a hash-mark following it. If there is no hash mark then it is impossible
> to talk about one of the two resources until somebody mints an
> appropriate URI.
> 
>  Paul Prescod
> 
> 
> 


-- 
Cheers, Tim Bray
         (ongoing fragmented essay: http://www.tbray.org/ongoing/)

Received on Wednesday, 30 July 2003 12:17:17 UTC