Re: What if two resources are the same subject?

Jon Hanna wrote:
> Quoting "Thomas B. Passin" <tpassin@comcast.net>:
> 
> 
>>Jan Algermissen wrote:
>>
>>
>>>>Well there is only one resource, but multiple URIs, 
>>>
>>>
>>>Ah, that I did not know. So resources may 'span across authorities', yes?
>>>A single resource can live on different hosts controlled by different
>>>authorities, yes?
>>>
>>>(I expect the REST camp to scream but if they agree, too, so much the
>>
>>better) 
>>

The above is not quoted from my writing, although I did myself quote it.
> 
> Consider that a resource can be anything, including physical objects like
> people. I know this isn't an entirely contention-free point, but while I
> can't speak for the entire REST camp Fielding's dissertation states:
> 
> "Any information that can be named can be a resource: a document or image, a
> temporal service (e.g. “today’s weather in Los Angeles”), a collection of other
> resources, a non-virtual object (e.g. a person), and so on."
> 
> So this would seem to be the REST position, or at least the orthodox REST
> position. With RDF it's hard to justify any other position if you are using
> URIs for things like predicates which are clearly abstract and don't "belong"
> to anyone).
> 

RDF uses the term "resource" differently from the REST usage, becuase in 
REST, a "resource" is something that can be be obtained as bits over a 
network - or at least a "representation" of it can - whereas an RDF 
resource can be abstract or otherwise non-network-obtainable.  The RDF 
usage seems to be pretty much the same as in the rfc for URIs, e.g., rfc 
2396

"A Uniform Resource Identifier (URI) is a compact string of characters
    for identifying an abstract or physical resource. "

Note that there is no rfc for "REST".

> Now, it simply isn't possible to have a single naming authority for every
> object
> and concept in existence (or not in existence, since fictional things can be
> identified) and it isn't practical to have a single naming authority for every
> object and concept of interest to everyone on the web. Even splitting the
> authority would require a centralised governing authority. Hence anyone who can
> coin URIs (uneasily governed by being in charge of a domain name) can coin a
> URI to identify anything.
> 

Right.

> That two or more URIs will identify the same resource is inevitable, and
> potentially fruitful (determining whether or not two URIs are identifying one
> or two resources may be very useful indeed, but two URIs are needed to allow
> for the possibility that they are two resources until that is determined).
> 

Right.

> 
>>You want to remember that the URI as used in an RDF statement is NOT 
>>being used as a REST-like GET-able representation.  It is purely an 
>>identifier.  What does it identify?  Ah, there's the rub.  IF it 
>>resolves to a retrievable resource, you could apply the convention that 
>>the resource "should" say cogent things about the thing identified by 
>>the URI.  In that case, the retrievable URL would be acting like a PSI. 
> 

The above paragraph _is_ something I said.

> I have to disagree.
> In RDF a URI is used to identify a resource (a thing).

But not necessarily a netwrok-retrievable thing.

> In REST a URI is used to identify a resource (a thing) and additionally if
> using
> it in a GET operation is successful then a representation of that resource will
> be returned.
> 

Right - bits (or documents if you like) get returned, not concepts or 
people.

> Since RDF has nothing to say about derefencing URIs once you dereference it
> you're in REST's territory, 

That does not follow.  I have nothing to say about how Federal Express 
routes packages, but that does not mean that I have to use Federal 
Express whenever I want to send one.

> not RDF's so a successful derefence should indeed
> provide say things about the thing identified by the URI (whether it's cogent
> or not depends on who or what is dereferencing, and why, so that can't be
> guaranteed).

Not the the subject identified by a URI is a web page itself.  The point 
is that even though it would be _nice_ if a dereferenced URI would be 
considerate and return useful information about the thing that is 
identified by the URI, that has no direct bearing on an RDF graph that 
is constructed by statements using that URI.  If the returned 
information were in RDF, those statements _could_ be merged with others. 
  None of this is mandatory, and none of this is required by a 
conforming RDF (or OWL) processor.

> In using URIs RDF is buying into REST to some extent, 

That's not in any RDF spec.  Of course, _if_ you choose to use an http 
URI as an RDF identifier, and _if_ you choose to return data when that 
URI is dereferenced, _then_ you will presumably be doing something 
REST-like.  But you could just as easily have a perfectly good RDF graph 
with non-http URIs.

> otherwise it would be
> better for it to use some other identifier system. Without the advantages of
> being able to buy into REST and inherit its goodness RDF would indeed be better
> off inventing a new identifier (domain names are a reasonable if imperfect way
> to partition authority within the namespace, but RDF has no direct use for
> schemes, and didn't need to inherit the growing pains URIs are having with
> non-ASCII characters).
> 
> 
>>  However, this is only a convention.
> 
> 
> URIs, RDF, XML, RDF/XML, HTTP and other web technologies are all conventions, I
> can send whatever I want to port 80 of a web server, it's by following the
> conventions that I might achieve something useful. It's all "only a
> convention".
> 

Yes, but they are conventions that are widely agreed on (even in a 
more-or-less formal way) and implemented.  They have become "standards". 
  The conventions we are talking about here are not (yet).  OTOH, 
widespread implementation of these kinds of ideas would make it clear 
whether they were adequate in practice and pave the way for a standard 
if they were.

Cheers,

Tom P

Received on Wednesday, 14 April 2004 09:34:30 UTC