RE: Valid representations, canonical representations, and what the SW needs from the Web...

> If we back off that assumption and allow there to be multiple ways for
> a URI to point to things, without unduly blessing one over all others,
> we're okay. And this mess becomes an RDF issue not a web architecture
> issue.  RDF works fine if it just becomes explicit about which way or
> ways each URI is being used.  All we need from webarch is to have them
> not pester us too much about using URIs to point to different things
> in different ways.

Well, that just seems to me to create disjunct systems that cannot
interoperate, since the names have no common interpretation, and
hence cannot address the interface between the Web and SW.

> > The groundwork of REST and the pairing of the concepts of resource
> > and representation are great, and serve the needs of the Web, ...
> 
> There are some things about REST that do not make sense to me.  I've
> raised the questions on this list, but if there were any responses I
> missed them.  (No blame here; the list has been crazy and no one has
> the job of explaining REST to me.   But since you seem to be
> volunteering, I'll go ahead and repeat my questions.)

Well, I don't consider myself a REST expert, but I'll offer my
comments based on my own (probably imperfect) understanding...

> >From [2]: How does REST handle the case of there being
> two different web pages about the same thing?  
> 
>     Perhaps one [web page] is more trusted than another, more timely,
>     more complete, or throws in fewer pop-up ads.  The user experience
>     is different on the two sites, yet as far as anyone can tell, the
>     sites are about exactly the same thing. Let's imagine the thing is
>     the Sun, and the locations are both mine. I declare
>     http://www.hawke.org/sun-a and http://www.hawke.org/sun-b to both
>     identify the Sun, and my server gives nice data at both addresses.
>     But on sun-b, sometimes I give the wrong data, because of a bug in
>     my software.  People learn this, and learn to stick with sun-a
>     instead. 

Why can't there be more than one name for the same thing? It may be
that both of the URIs above denote the sun, and the representations
provided are managed separately, and have differing characteristics
and quality, since representations may vary.

But I don't see a REST architectural problem here. One can say

   <http://www.hawke.org/sun-a> daml:equivalentTo <http://www.hawke.org/sun-b> .

and an application can choose which URI might provide more suitable
representations of the denoted resource. 

The real question is how you say one URI resolves to better
representations than another. How does one differentiate between
the URI, and the set of representations obtainable by that URI?

I think that TimBL's suggestions apply nicely here, in that http:
URIs denote web documents. And if you want to denote some abstract or
non-web-accessible resource such as the sun, you use some other
scheme of URI. I wouldn't myself opt for a URIref as I have problems
with that part of Tim's view (considering fragments as bound to
content structure and MIME type, not any arbitrary concept) but
would rather use another URI scheme entirely for abstract 
concepts, and then define where one might obtain web-accessible
representations for it. E.g.

   <voc://www.hawke.org/sun-a> rdfs:comment "Denotes the Sun" .
   <voc://www.hawke.org/sun-b> rdfs:comment "Denotes the Sun" .
   <voc://www.hawke.org/sun-a> daml:equivalentTo <voc://www.hawke.org/sun-b> .
   <voc://www.hawke.org/sun-a> x:representation  <http://www.hawke.org/sun-a> .
   <voc://www.hawke.org/sun-b> x:representation  <http://www.hawke.org/sun-b> .
   <http://www.hawke.org/sun-a> rdf:type x:Good .
   <http://www.hawke.org/sun-b> rdf:type x:Bad .

So, now we can talk about the sun (using either name), web-accessible
documents representing the sun (choice of two), and assertions about
the quality of the alternate web documents.

But I still don't see this as a problem with REST per se, but of
the common and misleading overloading of http: URIs which 
(traditionally at least) embody a web-document semantics and thus 
when used to denote resources other than web documents, results in
a conflict of denotation.

> >From [3]: 
> 
>     It's hard to accept the idea that there is one thing identified by
>     each URI when no one can tell me anything about that 
> thing, except in
>     trivial, made-up cases (like DanC's "this is a car" 
> page).  What thing
>     is, as far as you can tell, identified by
>        http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
>        http://www.uroulette.com/      [ used to pick the others ]
>        http://www.avianavenue.com/
>        http://ont.net/karate          [ 404, but don't let 
> that stop you ]
>        http://www.interactivemarketer.com/
>     ...? 

I agree that this is a practical limitation, but again, I don't
see it as a shortcoming of REST, per se, as defined for the Web,
but rather limitations of REST (or HTTP) to address SW needs.

I've long dreamed of a standardized mechanism by which one might
inquire from an HTTP server about all metadata knowledge available
from that server about a resource. E.g. GET-META rather than GET.
And thus, the owner of a URI not only may place one or more
representations of a resource on a server, but also any amount of
descriptive knowledge about the resource -- or even *only* metadata
about the resource, such as for non-web-accessible resources. Yet
that metadata is disjunct from any particular representation.

So, if you have a URI <http://ont.net/karate> you can GET-META a
representation of all knowledge known about that resource from
the server, and thus learn what it is, and what related resources
might be accessible (hmmm... sounds alot like RDDL, eh? ;-)

How that expands to knowledge brokerage servers and other specialized
servers supporting GET-META on resources with URIs not grounded in
the server's own web space is open to further exploration (but I've
got some ideas on that as well).

I've suggested such ideas to Roy and others before, but the
response can essentially be summed up as "the Web doesn't need that",
and hence the key point was apparently lost, that it's not the web
but the SW that needs it, yet by making it an extension of REST/HTTP,
that ensures a seamless intersection between the Web and SW.

Cheers,

Patrick

Received on Friday, 31 January 2003 11:04:04 UTC