capabilities lookup: it's the meta ...

[Ernst Johannes]

On Nov 16, 2005, at 22:01, Drummond Reed wrote:
> +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.

I think we we're misunderstanding each other, and it boils down to  
the use of the word "meta" which is one of the least understood and  
most befuddled words in the CS dictionary ... Maybe I should not have  
used it ... I was hoping to give my use of the word some precision by  
talking about specific examples, such as how to go from an object to  
its type. (I don't mean the broader meaning that some people seem to  
have in mind when they use "meta" as an equivalent of "summary", for  
example, which is an extreme use, admittedly)

To help clarify, let's call my specific use of the term "j-meta" for  
the time being, (Johannes' meta ;-)) to be clear that I have a very  
specific use of the term in mind, and only that.

Back to Drummond's e-mail:

These content formats are perfectly fine -- and they must be, because  
according to my book, content types are orthogonal to (what I just  
started calling) "j-meta" requests. This orthogonality is the issue,  
which one cannot represent by only talking about the content type.

Here's another example to illustrate what I mean. Let's say I have a  
blog at http://blog.example.com/.
1) An HTTP GET is made to http://blog.example.com/, with a content  
type preference of text/html. The content that comes back is my blog  
in HTML format, so people can read it
2) An HTTP GET is made to http://blog.example.com/, with a content  
type preference of application/rss+xml. The content that comes back  
is the very same blog in RSS (2.0) format. (Note there is no  
difference to #1 in content, it's just the surface format that is  
different)
3) An HTTP GET is made to http://blog.example.com/, with a content  
type preference of application/rdf+xml. The content that comes back  
is the very same blog in RSS (1.0 -- that happens to be RDF) format.  
(Note there is no difference to #1 in content, it is just the surface  
format that is different)

Note that #3 is not a "j-meta" request at all. It just uses a  
different content type, which happens to be RDF. If this particular  
blog implementation had decided it didn't want to support XML 1.0  
(aka RDF), it could have returned an RDF file in response that  
contained true "j-meta" data. Which illustrates that content type is  
insufficient to determine whether or not returned information is or  
isn't "j-meta".

> So if you have
> Peter's example resource "http://example.foo/me", 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)

I believe your example is consistent with my example above -- so we  
just have a misunderstanding here, not a disagreement.

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

Of course, the issue of what "j-meta" information is and what not  
gets confused by a number of document formats on the web -- actually  
most of them -- that carry some kind of j-meta information inside the  
very file, for all sorts of (usually good) reasons. For example, an  
XML file with an in-lined DTD is most certainly containing both  
information (the data) and other information (the types) that have a  
"j-meta" relationship to each other.

HTML is another example -- which is why we have a "META" tag in HTML.

But the best example may be XML: An XML DTD is "j-meta" with respect  
to one or more XML instance files, and in this case, the content  
types for XML instance information and DTD information are actually  
different (application/xml vs. application/xml-dtd). But then these  
guys went ahead, defined XML Schema -- which uses XML itself! -- and  
the trick with the content types that started this thread is not  
working any more, because we cannot distinguish the data and the j- 
meta-data simply by looking at the content type: they are both  
application/xml! We need to represent that "j-meta" relationship  
differently ...

We have the exact same situation here with the capabilities here in  
YADIS, which suggests that solutions could be similar. And in fact,  
the XML approach of embedding a URL pointing to the "j-meta"  
information (aka its DTD or schema) is part of the current YADIS  
draft: "read the HTML document, look for the special tag -- here a  
LINK tag, but it doesn't matter what its name -- and when going to  
that URL, you will find the j-meta data there". There have been other  
proposals made on this mailing list to embed all the j-meta data into  
the HTML itself -- just like an embedded DTD in XML.

The reason this discussion started in the first place is that we  
didn't like relying on parsing HTML files (who are notoriously  
syntactically challenged), we didn't want to require users to change  
their HTML files, we didn't want to limit ourselves to URLs that  
return HTML, and we wanted to have a mechanism which is bandwidth /  
#requests-required optimized by having the ability to get the j-meta  
data directly under certain circumstances.

Will send a proposal later today ... in the meantime, if you disagree  
with my analysis, this is a good time to raise your concerns ... ;-)




Johannes Ernst
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/yadis/attachments/20051117/c3bb979b/lid.gif
-------------- next part --------------
  http://netmesh.info/jernst