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

John,

 

Thanks for the examples. They help illustrate the concept very clearly. I
agree it seems quite solid, but I am not an HTTP expert (and don't even try
to play one on Internet TV ;-), so I'm keenly interested in what TAG members
and others on the list think.

 

=Drummond 

 

  _____  

From: John Bradley [mailto:john.bradley@wingaa.com] 
Sent: Friday, September 12, 2008 9:41 PM
To: Drummond Reed
Cc: 'Booth, David (HP Software - Boston)'; www-tag@w3.org
Subject: 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.

 

 

Received on Saturday, 13 September 2008 05:04:11 UTC