capabilities lookup: it's the meta ...

Drummond Reed drummond.reed at
Wed Nov 16 22:01:20 PST 2005

+1 to Peter's suggestion. I like the way Johannes framed the overall problem
-- how to consistently get metadata about any resource -- but I agree with
Peter that metadata about a resource IS a representation of the resource.
The Web community has several longstanding precendents for this -- both RDF
and RDDL description formats are registered content types. So if you have
Peter's example resource "", you can use that URL to
ask for:

* Its RDF representation (application/rdf+xml)
* Its RDDL representation (application/rddl+xml)
* Its XRDS representation (application/xrds+xml)

If a user only has the ability to provide HTML at the location of the URL,
then I agree w/Peter that YADIS should allow user to either embed the XRDS
metadata in the HTML or use a link element to point to the XRDS file.


-----Original Message-----
From: yadis-bounces at [mailto:yadis-bounces at]
On Behalf Of Peter Davis
Sent: Wednesday, November 16, 2005 12:31 PM
To: yadis at
Subject: Re: capabilities lookup: it's the meta ...

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'
( 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

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



On 11/16/2005 12:36 PM, "Ernst Johannes" < at>

> 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

=peterd  (

More information about the yadis mailing list