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.

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