capabilities lookup: it's the meta ...
drummond.reed at cordance.net
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 "http://example.foo/me", you can use that URL to
* 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.
From: yadis-bounces at lists.danga.com [mailto:yadis-bounces at lists.danga.com]
On Behalf Of Peter Davis
Sent: Wednesday, November 16, 2005 12:31 PM
To: yadis at lists.danga.com
Subject: Re: capabilities lookup: it's the meta ...
This debate has much history @ the W3C, FWIW, at , with still no clear w3
recommendation on the matter.  has some interesting thoughts on the pros
and cons on the subject, and nearby  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
On 11/16/2005 12:36 PM, "Ernst Johannes" <jernst+lists.danga.com at netmesh.us>
> 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)
> 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
> 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
More information about the yadis