RE: Proposed issue: site metadata hook

> > One simple way to implement this recursive naming is by
> > means of a standardized URI infix, so that when MGET is
> > called on
> >
> 
> NOT standard!   We are trying to AVOID standardizing that space.
> As you note later on, the server can chose it.

I agree fully. I was only pointing out *one* possible solution,
which demonstrates that there is no MMMMMMGET problem, as you
suggested there was.

And I fully agree that we should not stray into the domain
of the web authority.

> It doesn't need to be standard. You always get it from the Metadata:
> after a HEAD or GET or the URI: after a MGET.

But that requires two system calls to get metadata, rather than 
one *and* it means that you have to GET the knowledge, which
returns a representation, which is a lottery -- you never actually
*know* what that representation might contain.

MGET returns a bounded description with specific characteristics,
not an arbitrary, unknown-beforehand representation.

It is the set of RDF statements known to the server where the
resource specified is the subject, and recursively, for all
blank node objects, all statements with those blank nodes
as subjects.

Using GET is just too ambiguous, as you can't reliably ask
for such a precise, bounded description of a resource, and
even if one is lucky to usually get such a thing, I think
the SW needs a bit more consistency and precision that that.

> Our site tends to use comma suffixes -- http://www.w3.org/,tools

Right, but that is just as non-standard as http://www.w3.org/MGET/tools

I wouldn't want to see either convention made standard.

I'd rather see the same URI being used to access either representations
or descriptions, depending on whether one is browsing the Web or
the Semantic Web.

> >    http://example.com/foo
> >
> > the RDF/XML returned contains statements describing the
> > resource denoted by http://example.com/foo and that entity
> > returned by HTTP has a URI of
> >
> >    http://example.com/MGET/foo
> >
> > which denotes the body of knowledge available via MGET from
> > that particular server about the resource http://example.com/foo
> >
> > If one were to do a GET on http://example.com/MGET/foo, one
> > would obtain the same RDF/XML encoded knowledge as one would
> > get by doing an MGET on http://example.com/foo.
> >
> > HOWEVER, if one does an MGET on http://example.com/MGET/foo
> > one gets a description about the body of knowledge known by
> > the server about http://example.com/foo, with a URI
> > of http://example.com/MGET/MGET/foo
> >
> > Thus, the URI of the body of knowledge about the body of
> > knowledge about the body of knowledge about the body of
> > knowledge about the body of knowledge known about the
> > resource denoted by http://example.com/foo is
> > http://example.com/MGET/MGET/MGET/MGET/foo, etc...
> >
> > Simple.
> 
> Yes. It could work just like that using GET and Metadata: too.

Not exactly, because

1. GET and Metadata: requires two system calls, not one
2. GET on the URI specified by Metadata: returns a representation,
   not a precise description with tighly constrained characteristics

Thus, GET + Metadata: is both less efficient and less precise
than using MGET

> > Downright silly, to be sure, but simple nonetheless and
> > it will work just fine, thank you very much.
> >
> > However, I suspect you are mostly thinking about documents
> > describing resources, and the URIs of those documents. Well,
> > that's what rdfs:isDefinedBy is for. No?
> >
> > And the content of the body of knowledge about a resource
> > known to a server may very well be the syndication of
> > knowledge from multiple documents and/or other servers.
> >
> > If you have a document that expresses knowledge about a
> > resource, and a server which supports MGET which has syndicated
> > knowledge from that document, or at least is aware of the
> > descriptive nature of that document, one would expect that the
> > knowledge returned by MGET would include an rdfs:isDefinedBy
> > statement indicating the URI of the document from which
> > the knowledge originated.
> 
> Well, you'd need N3's formulae or equivalent to distinguish 
> information
> from other sources... yes we could do all kinds of things.
> This proposal is just for the hook. The wonderful recursive things one
> could do would follow....

And my MGET proposal is also about the hook, but a more efficient
and precise hook, which reflects the compimentary relationship
between the Web and the Semantic Web, as each reflects different
ways to interact with the *same* URIs which denote resources.

GET + Metadata: forces us to explicitly define URIs to denote
the body of knowledge known by a server about a resource, even
if we never expect to say anything about that body of knowledge.
And even if those URIs can be automatically generated as a
regular permutation of the URI denoting the resource, it still
unnecessarily forces the duplication of URIs on the Web.

> > Then, the agent would GET the specified document and
> > do what it needs with it.
> >
> > And if one wanted knowledge about the document, well
> > just MGET it using the very same URI of the document.
> >
> > It's really devilishly simple.
> >
> 
> It is very similar to the use of HEAD and Metadata: and in fact they
> are NOT mutually exclusive.  It is easier to introduce a header,
> I think.  but in any case, this is really a question as to whether
> we want a hook.

I would think that the amount of effort in supporting a new method
is on par with that of supporting a new tag, so neither is more or
less of an implementational burden.

However, from a processing point of view, which is more efficient,
double the number of system calls a semantic web savvy agent has
to make to a server and double the total number of URIs on the
web, as well as add additional vocabulary support to all servers,
or to simply add additional vocabulary support to all servers (but
in the form of new SW specific methods) and have single system
calls as we do now with GET and use the very same URIs we now
have, without need for more?

I think the latter is clearly more efficient.

MGET also does not force any changes to the semantics of HTTP
as now defined or any change in the behavior of current web
servers. Just as with WebDAV, it is simply an extension, an
additional layer if you will, on top of present the Web
architecture.

> > And of course, the URI of the body of knowledge known about a
> > web site http://example.com would be http://example.com/MGET ;-)
> >
> > Furthermore, a server is free to specify whatever URI it
> > likes to denote the body of knowledge returned by MGET.
> 
> good.
> 
> 
> > It
> > need not use anything like the above MGET infix. It might
> > just use UUIDs and track returned entities per session.
> > Whatever. It really doesn't matter. Though, of course, the
> > MGET infix is more in line with "Cool URIs don't change" ;-)
> >
> > In fact, if that body of knowledge is actually taken from a
> > specific document, say http://example.com/foo.rdf then one
> > would expect the server to provide the URI of the entity
> > returned from an MGET to http://example.com/foo, since that's
> > the actual resource being returned.
> >
> 
> Indeed.
> 
> > --
> >
> > So, I hope it is now clear that here really is no kind
> > of MMMMMMMGET problem.
> >
> 
> I am so glad.  I hate MMMMMMMMMMGET problems. ;-)

So do I.

> I guess it comes down to which is easiest to introduce, or if you
> like, whether a single-round-trip metadata access is deemed
> worth introducing an extra method (which is generally
> expensive to get adopted).

Well, adoption of any kind of semantic web extensions is going
to involve the introduction of some form of knowledge base and
the ability to query that knowledge base. The parallels with
WebDAV are significant.

If folks want to have a Semantic Web Enabled server, they will
have to add components. And if those components consist of a
layer which provides that knowledge base and understanding of
the additional methods, then that is cleaner and simpler IMO
than having to modify existing server behavior to include
particular tags in the headers and modify the semantics and
behavior of the server when responding to GET, HEAD, etc.

Furthermore, having the SW specific set of methods clearly
distinguishes the parallel relationship between the Web and
the Semantic Web.

Web agents traverse the web via GET using URIs denoting resources.
Semantic Web agents traverse the semantic web via MGET using
the same URIs denoting the same resources as the Web.

GET returns representations of the resources.
MGET returns descriptions of the resources.

And the descriptions returned by MGET to SW agents are highly
precise, bounded entities optimized for the needs of semantic web
agents, rather than fuzzy and unpredictable representations
intended for human users.

Thus the Web and Semantic Web are just two different ways of
interacting with a global inventory of URIs denoting resources
(rather than two parallel inventories of web URIs and semantic
web URIs having some kind of 1:1 relation)

Patrick

Received on Wednesday, 12 February 2003 04:23:19 UTC