Re: Using HTTP Headers to Request Descriptors (was RE: [XRI] Back to XRI)

Drummond,

I think you have the essence of the idea.

XRDS-Simple uses the mime type to indicate that you want the meta data  
for the object.

I think that TimBL is correct that this is a inappropriate overloading  
of the accept header.

People do it because there dosn't seem to be another good alternative.

I found reference to Nokia's MGET,  but asking to add new methods to  
http, might make XRI look like a good idea in comparison(to some  
people).
http://sw.nokia.com/uriqa/URIQA.html

I want a simple way to directly request the meta-data that is  
associated with a "non-information resource"

Apologies in advance to Ray Denninburg for butchering a book example.

If the non-information resource is a book for instance say "So long,  
and thanks for all the fish"

Lets take the WorldCat URI as the example identifier.
http://www.worldcat.org/isbn/0517554399

This is referred to by different people as  a "abstract identifier",  
"identifier of abstract resources", and "non-information resource  
identifier"

If I want meta data for the author of the resource I can do a head on  
the URI and inspect the Link headers to find something like:
Link: <http://www.worldcat.org/search?q=au%3ADouglas+Adams>; rel="http://purl.org/dc/elements/1.1/author 
"

If I knew in advance that I wanted the author meta-data I could  
include a Link Header in the request such as:
Link:  rel="http://purl.org/dc/elements/1.1/author"

This asking the server for the Author metadata by referencing Dublin  
Core.
The server can include the above link header in the response and give  
me a 303 redirect to the URI for the Author meta-data.

In some cases the server may reply directly with the meta data but  
still include the link header for the URI to directly access the meta- 
data resource.

In the real wold the web is not a friendly place for non-information  
resource identifiers so my example is a bit contrived.

I am trying to imagine something that fits the XRDS-Simple/HXRI use  
cases but is general enough to be used by others within the AWWW  
architecture.

Having the web server take SPARQL queries in the header would be  
interesting but overkill.

Using the link header as a way to make a query or do metadata  
negotiation as some may put it,  seems like a reasonable proposition.

I am entirely open to and interested in counter proposals.

Regards
John Bradley


On 12-Sep-08, at 4:55 PM, Drummond Reed wrote:

> John,
>
> I changed the subject line because the approach you suggest for  
> using an HTTP Link header to explicitly request a description of a  
> resource (“descriptor”) seems particularly promising. “Finding  
> Resource Descriptions” [1] has many good references to discussions  
> around this topic, but most of them seem focused on how to return  
> links to descriptors in HTTP responses, not how to explicitly  
> request them. Other resource descriptor formats like POWDER [2] also  
> seems to focus on Link headers in responses vs. requests.
>
> What I like about putting this semantics in a request header is that  
> it could be explicitly defined to mean: “If possible, give me (or  
> redirect me to) a descriptor of the target resource that has this  
> specified relationship (rel= value) to the target resource.” And if  
> the value of the rel attribute was a URI, then there would be no  
> limit to the types of descriptors that could be requested and  
> potentially returned directly, without any extra round trips and  
> with very precise semantics.
>
> In effect, it would be like the client explicitly asking the server  
> for a 303, but being able to specify the precise type of related  
> resource the client is seeking, and for the server to actually  
> return that resource directly if it has the ability to do so. And  
> because the semantics would be explicit that the client is asking  
> for a descriptor of the resource and not the resource itself, it  
> would get around the problem described near the end of [1]:
>
>             “If you ask for RDF, you get the description. If you ask  
> for something else, you get the thing described. (The TAG, TimBL,  
> and others have pointed out that this contradicts web architecture,  
> which requires that content negotiation choose among things that all  
> carry the same information. That goes for CN between RDF and HTML as  
> much as it does for CN between GIF and JPEG.)”
>
> Do I understand this correctly?
>
> =Drummond
>
> [1] http://esw.w3.org/topic/FindingResourceDescriptions
> [2] http://www.w3.org/TR/powder-dr/
>
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On  
> Behalf Of John Bradley
> Sent: Friday, September 12, 2008 1:42 PM
> To: Booth, David (HP Software - Boston)
> Cc: elharo@metalab.unc.edu; www-tag@w3.org
> Subject: Re: [XRI] Back to XRI
>
> David,
>
> Having the meta-data at a known relative location to the "about-a- 
> thing" URI is more practical where we have URI that all conform to  
> the same rules through the proxy by say adding $XRDS to the path or  
> query as an example.
>
> It however prevents us from having a rule that all URI in a given  
> space all of the URI are "about things" and not things themselves.    
> This could be finessed if required.
>
> A larger problem is for XRDS-Simple if the general rule is to add  
> $XRDS to the path and there is no document at the location the  
> client needs to go back to the original URI preform a HEAD or GET  
> and retrieve the X-XRDS-Location header or Link header if we  
> standardize on that.
>
> A failure takes XRDS-Simple from 2 GETs to 3 GETs.
>
> What would be ideal is if there was some equivalent to the Link  
> Header for requests.
>
> In my GET I would like to say
> LINK:  rel="http://docs.oasis-open.org/xri/2.0/specs/xri-resolution-V2.0.html 
> "
>
> I don't think that the ability to ask for an "information resource"  
> that has a relation to a "non-information resource" is unreasonable.
>
> I feel frustrated, in that responses have the ability if limited, to  
> express relationships from "non-information resources" to  
> information resources.
>
> I want to say give me the XRDS information resource for the  
> =jbradley "non-information resource".
>
> I imagine that in response to such a request a Web Server might  
> return:
> 1. The related document with Link Headers describing the relationship.
> 2. A link header describing where to find the related document and a  
> 303 to the related document or some other related document described  
> in the Link headers.
> 3. A link header describing where to find the related document,  and  
> some other HTML representation of the resource.
>
> 3 is a use case by Yahoo and others who never want to return the  
> metadata from a URI that also delivers content.  This is due to the  
> unpredictable behavior of proxies respecting vary.
>
> As an example yahoo.com  returns content.  It is also the realm for  
> describing the oAuth and other services Yahoo provides.
>
> Because of there volume Yahoo, Google and others only want to serve  
> the Link header describing where to find the XRDS for the realm to  
> clients that specifically ask for it.
>
> Someone must have brought up a similar use case before.  Asking for  
> relationship information in a request is the obvious next step from  
> supplying it in a response.
>
> Perhaps I am missing something,  or my question is in some way  
> heretical.  It certainly wouldn't be the first time.
>
> Your input is appreciated.
>
> Regards
> John Bradley
>
>
> On 12-Sep-08, at 12:46 PM, Booth, David (HP Software - Boston) wrote:
>
>
>> From: John Bradley [mailto:john.bradley@wingaa.com]
>> [ . . . ]
>> One of the things that we need the most work on is how to
>> perform what
>> might be thought of meta-data content negotiation for URI that are
>> about "things".
>>
>> The best solution we have found at this point is to use Link Headers
>> to indicate where the related meta-data can be found at distinct URI.
>> This is would be consistent with Mark Nottingham's draft
>> recommendations:
>> http://www.mnot.net/drafts/draft-nottingham-http-link-header-01.txt
>> This clearly requires an extra GET that some users are resistant to.
>
> If the metadata can be in an arbitrary location then it does sound  
> like the extra GET may be unavoidable.  But if the metadata can  
> always be at a predictable location relative to the original URI,  
> and you can figure out a simple pattern matching rule to convert the  
> original URI to the metadata URI, then a smart agent could inspect  
> the first URI, determine that it uses the XRI http subscheme  
> convention, and use the pattern match to transform it into the  
> metadata URI without doing a GET on the original URI.  Would that be  
> a viable approach for you?
>
>
>
> David Booth, Ph.D.
> HP Software
> +1 617 629 8881 office  |  dbooth@hp.com
> http://www.hp.com/go/software
>
> Statements made herein represent the views of the author and do not  
> necessarily represent the official views of HP unless explicitly so  
> stated.
>