Re: What if two resources are the same subject?

Quoting "Thomas B. Passin" <tpassin@comcast.net>:
[snip]
> Jon Hanna wrote:
> > Quoting "Thomas B. Passin" <tpassin@comcast.net>:
[snip]
> >>Jan Algermissen wrote:
[snip]
> The above is not quoted from my writing, although I did myself quote it.

I thought I was making that sufficiently clear by including the citation line.
I apologise if it seemed I was putting words in your mouth. (Darn, I do that to
people often enough through sloppy quoting, I'd really hate to do it when I
took pains not to).

> 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.

A representation can be created of anything that can be conceived of well
enough to find its way into a model, be that model RESTful, RDF-based, or
otherwise.

The quote from Fielding I gave quite clearly includes non-network-obtainable
resources, in particular "a non-virtual object (e.g. a person)". Being a REST
proponent doesn't necessarily mean you agree with Fielding on everything, but
that document can be safely considered to contain REST orthodoxy, if you don't
think REST views URIs as capable of identifying non-network-obtainable resources
the burden of proof is on you.

It's perfectly possible to download a representation of a
non-network-obtainable
object such as a person. <http://www.hackcraft.net/jon/> returns a
representation of myself (in HTML or RDF/XML depending on Accept headers)
though I am clearly not downloadable.

For that matter downloadable resources tend to be of limited interest in and of
themselves, apart from software and software patches most people generally
aren't that interested in the 1s and 0s, but in what those 1s and 0s represent
(the exception being if you are building, debugging or critiquing the web
application itself).

  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".

There are however several RFCs based on or influenced by the REST style, of
which RFC 2396 is one. The point of developping REST was to guide the
development of web technologies like URI, HTTP and for that matter RDF.

> >>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.

If we're interested in bits we should have probably stuck to FTP.
Representations of resources, including concepts or people - composed of bits -
get returned (possibly) but the concepts or people are what one is interested
in. That is why we distinguish between resources and representations.

> > 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.

It does if you phone up Federal Express and ask them to come around and collect
it. A closer analogy is that people can, and do, use postal codes/zip
codes/etc. as general geographic identifiers, but the postal services won't
change how they use them.

> > 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.

Why bother? Really? While this list is likely to contain many people who find
XML, HTML, RDF/XML or whatever format is used for a web page to be interesting
in and of itself, it hardly seems worth having a network of millions of
computers just for us. Web pages are a means and the end is more important.

  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,

Why would one bother to return anything else? (beyond a 404 or similar error
message).

> > In using URIs RDF is buying into REST to some extent, 
> 
> That's not in any RDF spec.

RDF uses URIs, URIs are a technology whose design was guided by REST, Quod Erat
Demonstrandum.

  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.

Yes, or with http URIs that don't resolve. That doesn't invalidate the influence
of REST on RFC 2396.

> >>  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.

Certainly whether you or I have the more practically useful view of the
relationship between RDF or REST is more useful than how many graphs dance on
the head of a URI. I think we have agreement on that at least :)

Regards,

-- 
Jon Hanna
<http://www.hackcraft.net/>
"…it has been truly said that hackers have even more words for
equipment failures than Yiddish has for obnoxious people." - jargon.txt

Received on Wednesday, 14 April 2004 10:28:31 UTC