- From: Sandro Hawke <sandro@w3.org>
- Date: Fri, 31 Jan 2003 12:17:03 -0500
- To: Patrick.Stickler@nokia.com
- cc: www-tag@w3.org
> > 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. Yes, for interoperability my approach requires standardizing on name-mapping functions as we need them. I took at stab at describing two of them [ kb(uri) and subject(uri) ] earlier in this thread. Those are the two I seem to need most in my work. But if I try to claim either of them is *THE* web denotation function, I'd probably get in a lot of trouble. > Well, I don't consider myself a REST expert, but I'll offer my > comments based on my own (probably imperfect) understanding... ... > 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'm with you here. But we're in the minority on httpRange-14. Lots of people (including Graham Klyne and Brian McBride according to their recent postings here) seem to think it's perfectly reasonable to use http URI strings to denote people. > 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) I'm with you there, too. > 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> . [ of course that would be inferred by daml inference ] > <http://www.hawke.org/sun-a> rdf:type x:Good . > <http://www.hawke.org/sun-b> rdf:type x:Bad . Yes -- that's the approach I advocated back when I proposed "tag" URIs. But TimBL objected, saying it wasn't "clickable", that using http gave the SW more of the interconnectedness of the traditional web. I'm 70% convinced he's right. > 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. I hear REST advocates saying one can and should use http URIs to denote people. Since you don't hold that position, I guess I'll have to wait for someone else who does to address my 2-pages-about-the-sun problem. > 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. Yes -- if httpRange-14 were settled to be webDocuments as TimBL suggests, then REST would be fine for the SW. Well, except we'd still have the fragments problem. My two functions kb(uri) and subject(uri) solve the fragments problem: kb(http://www.w3.org/1999/02/22-rdf-syntax-ns#type) is a portion of kb(http://www.w3.org/1999/02/22-rdf-syntax-ns); the exact approach to fragmenting depends on the media type, but I'd expect it to be the fragment most definitive of "type". This is about what you get if you think of RDF/XML as XML, and rdf:ID as an xml:id -- the fragment is an XML Element (an rdf:Description of "type"), which by itself parses to an RDF graph conveying some information about it. Here you might want to have an infoset(uri, world) function, mapping you from the uri to the XML inforset there, but need the "world" parameter to handle change-over-time, etc. This view suggests the RDF/XML media type definition should define fragments as like XML ids, but with the RDF graph first re-serialized to start at that node. (That's a reasonble operation for the client to do in interpreting the fragment identifier, I think, but I haven't implemented it. Do you include the whole subtree from that node as the root, or just depth=1? I guess depth=1 gives you all you need, so that's proper.) subject(http://www.w3.org/1999/02/22-rdf-syntax-ns#type) is the RDF "type" predicate, which happens to be described in that KB fragment. > 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? ;-) I wanted GET-META so I could know when/how to query an RDF database, instead of just using GET to dump the whole thing. But then I thought about how this works these days -- amazon has a really big DB which you never access directly, but through various interfaces. I jotted down the view(uri) function [1], but lets see if I can flesh that out some more. Basically kb(uri) = apply(query(uri), backingKB(uri)) That is, the information presented at some URI can be seen as the result of applying some query to some backing information. >> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html kb(uri) = the HTTP/1.1 status code definitions query(uri) = (trivial) what are the HTTP/1.1 status code definitions? backingKB(uri) = the expert knowledge of the HTTP/1.1 WG >> http://www.uroulette.com/ kb(uri) = intro to uroulette, info about how to use their service query(uri) = (trivial) backingKB(uri) = their table of URLs ++ http://lists.w3.org/Archives/Public/www-tag/2003Jan/0150.html kb(uri) = the text of an email, and various links to related email and pages query(uri) = (a complex algorithm to sort out threads) backingKB(uri) = W3C e-mail archives ...etc. Now the kb(uri), if it's being nice, will give you information about the query(uri) and the backingKB(uri). It may even tell you uri2, such that kb(uri2)=backingKB(uri1); then you could use http GET to directly dump the backing KB. What you actually GET via HTTP is (of course) not the KB and not the contents of the KB at that point in time; it's a serialization of the contents of the KB at that point in time. The selection of a serialization procedure to use for any given request depends on "accept" headers, etc. > Patrick -- sandro [1] http://www.w3.org/2003/01/web/#view
Received on Friday, 31 January 2003 12:17:34 UTC