Re: Proposed issue: site metadata hook

On Tuesday, Feb 11, 2003, at 08:09 US/Pacific, 
Patrick.Stickler@nokia.com wrote:

>
>
>> -----Original Message-----
>> From: ext Tim Berners-Lee [mailto:timbl@w3.org]
>> Sent: 11 February, 2003 15:15
>> To: Stickler Patrick (NMP/Tampere)
>> Cc: www-tag@w3.org; tag@w3.org
>> Subject: Re: Proposed issue: site metadata hook
>>
>>
>> And what, then, is the URI of the URI of the information about the
>> resource?
>>
>> (do we have MMGET to get metadata about that?)
>
> Certanly not.
>
> Surely you are not suggesting that there cannot exist resources
> without names? ;-)
>

Only that, if they are information-containing resources,  it is less
useful if they do not have an identifier.
This is a tenet of the Web.

> The body of knowledge returned by MGET *is* a resource, but
> one need not say anything about it or give it a name if one
> does not need to (and I expect most folks won't).

And one cannot if one does need to?

> But if you *do* want to, you can return the URI of that
> body of knowledge in the HTTP headers using a tag such as
> URI: a'la Apache (though with absolute rather than relative
> URIs), or something akin to it, as is commonly done in content
> negotiation to identify the particular entity (variant) being
> returned, to differentiate it from the resource denoted in the
> HTTP request.

Ah, that is true, one could return a URI in the headers.


> Then, if you like, and if any knowledge is defined about it,
> you can do an MGET on that URI, and get back, along with the
> results, yet another URI denoting *that* body of knowledge,
> and iterate ad nauseum until bored.

Indeed.  One could do this with GET and Metadata: header of course too.

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

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.

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


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

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

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

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

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


> Cheers,
>
> Patrick

Received on Tuesday, 11 February 2003 16:09:31 UTC