capabilities lookup: it's the meta ...

[Peter Davis]

This debate has much history @ the W3C, FWIW, at [1], with still no clear w3
recommendation on the matter. [2] has some interesting thoughts on the pros
and cons on the subject, and nearby [3] as well.

The two main camps debating this within the SEMWEB community is <link> vs
'Accept:'.  If you are using a LID/openID URI as the 'identifier'
(http://example.foo/me) for an identity, and you seek metadata about this
identifier (eg what are it's capabilities), then I think this _is_ a
specific representation of the resource identified by http://example.foo/me

Personally, I think what you end up with is BOTH.  Some can hack HTTP
headers, others will not be able to (like my blogspot blog), in which case,
I can simply insert XRDI directly into the (HTML?) representation of the
resource located at http://example.foo/me, or p[lace a <link> element there.

'YADIS UserAgents/Clients' which supported content negotiation may try that
first, followed by scanning the HTML for either embedded XRDI or a linked
XRID.

=peterd 


[1] http://www.w3.org/2001/sw/
[2] http://esw.w3.org/topic/EmbeddingRDFinHTML
[3] http://esw.w3.org/topic/SlashRedirection

On 11/16/2005 12:36 PM, "Ernst Johannes" <jernst+lists.danga.com at netmesh.us>
wrote:

> Something else had been bothering me about some of the capabilities
> lookup alternatives that we'd been discussing. I hadn't quite been
> able to put it into words, but finally, now I know what it is ... and
> I'm eager to share ;-)
> 
> FIrst, a rehash.
> 
> The operation that we are trying to define is
> "given this URL, tell me what its capabilities are"
> 
> Then, an insight.
> 
> This is, if there ever was one, a "meta" traversal. Similar to
> "given a Java/C#/Perl/PHP/whatever object, tell me what methods I can
> invoke on it", or
> "given a URL, tell me what its properties are" (like the PROPFIND
> method in WebDAV)
> 
> Conceptually:
> This is not about obtaining the resource according to a different
> surface representation.
> This is also not about qualifying the GET operation of the URL with
> additional parameters.
> This is a genuinely new kind of method, a "META" method, so to speak:
> we are not attempting to "GET" the resource, or "POST" or "PUT" or
> "DELETE" etc. -- instead, we are asking for its meta-data. (well, a
> particular kind of its meta-data, namely what YADIS calls its
> capabilities)
> 
> This is worth repeating: It is a GET, but not of the resource, but of
> its meta-data.
> 
> Maybe the best parallel, in a language such as Java, would be
> "given this object, tell me what interfaces it supports". (please
> interpret the word "interfaces" loosely here, on the same abstraction
> level as capabilities in YADIS, I don't mean to talk about GET and
> POST etc.) as opposed to "give me an HTML or TXT or Serialized
> representation of the object" which would be an entirely different
> kind of request.
> 
> So ...
>   ... the conceptually cleanest way to support this "meta" operation
> would be to add a new verb to HTTP ("GETMETA" comes to mind) -- like
> WebDAV did. In fact, there are many parallels here because a big
> chunk of what WebDAV is all about is to deal with additional meta-
> data that plain HTTP knows nothing about.
>   ... but assuming we don't want to define additional verbs for the
> REST / HTTP vocabulary, which would probably be a bad idea for a
> range of other reasons
>   ... assuming that you guys agree with me that "meta" is really what
> this is all about
>   ... the engineering problem in front of us seems to be:
> 
> "given that we have a genuinely different kind of operation on a URL
> than people normally do these days" (side note: I very much agree
> with Mart's comment on the wiki that this capabilities/meta lookup is
> going to be much more broadly useful than "just" for identity) "how
> are we best going to use the means at our disposal to emulate this
> new operation?"
> 
> Is that an accurate description of the problem?
> 
> Note that any "meta" operation (whether in YADIS or wherever) is
> genuinely orthogonal to any parameters that specify which format the
> client wants the response to be in. Just like in plain normal use of
> HTTP, as a client I should be able to say "I like HTML better than
> PDF better than TXT" (if I'm a human) vs. "I like XML only" (if I'm a
> machine) for the meta-data of the URL, not just the resource behind
> the URL.
> 
> That's the other thing that has bothered me in the current proposals
> without being able to express it so far: we seem to have assumed that
> the capability query only makes sense for machine clients. But upon
> reflection, I don't think so: as a human, I also want to know what a
> given URL can do, and I want to know in HTML because I like it better
> than PDF better than TXT and I don't like XML. (Just as an example
> for the preferences of a human client).
> 
> Ergo, the "Accept" specification is, and must be, orthogonal to the
> "Meta" specification (in whatever form we will settle on), in order
> to be architecturally clean.
> 
> In other words, I have decided to be very much against (sorry, guys)
> using the Accept header to emulate a "Meta" operation because it
> collapses two orthogonal things onto the same dimension, and that is
> a big no-no in the architecture book that I'm following ... because
> sooner or later, we'd want to disentangle the orthogonal dimensions
> and we won't be able to if we go down that route.
> 
> Can we agree on whether this is an accurate description of the
> problem first before figuring out what that means for the protocol? I
> would have a proposal that turns out to be only a minor
> modification ... but problem description first.
> 
> 
> 
> 
> Johannes Ernst
>   http://netmesh.info/jernst
> 
> 
> 

=peterd  (http://public.xdi.org/=peterd)