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

Jonathan,

 

Thanks for the analysis - it is very helpful. You close by saying:

 

            "I agree with you that a uniform, widely deployed metadata
protocol not requiring that extra round trip and not specific to any
particular class of URIs (such as XRIs or HXRIs) would be a nice thing, but
while technically this is very easy, socially and politically it does not
seem to be coming about. If you want to discuss this, or to design and
promote something that could be used not just for HXRIs but for all URIs (or
all http: URIs), I wouldn't object."

 

I completely agree that such a metadata protocol should be able to work for
all URIs. The XRDS discovery protocol currently being used by XRI, OpenID,
and OAuth is something that already works for both XRIs, http: URIs, and
https: URIs. However it uses the Accept header to request the XRDS
descriptor associated with the identified resource, which leads to the
problem we are now trying to solve.

 

Assuming the POWDER community and other communities that need metadata
discovery also have the same motivation, it would seem that there is some
real momentum to work this out. What would the TAG suggest as the best way
to proceed?

 

=Drummond 

 

  _____  

From: Jonathan Rees [mailto:jar@creativecommons.org] 
Sent: Saturday, September 13, 2008 10:44 AM
To: Drummond Reed
Cc: John Bradley; Booth, David (HP Software - Boston); www-tag@w3.org
Subject: Re: Using HTTP Headers to Request Descriptors (was RE: [XRI] Back
to XRI)

 

Using *any* kind of special header to try to make a GET do something other
than getting a representation of the denoted information resource (speaking
TAGese now) would violate the HTTP 1.1 RFC. This applies to equally to
content negotiation, a client-provided Link: header, and any other similar
hack. Not only would it violate the RFC but it would risk confusing caches,
proxies, and other intermediaries and tools.

If you want to use a protocol that is beginning to get traction with both
servers and clients, and works for any referent, use 303. (303 works fine
with information resources, except that a client has to do something other
than a direct GET to obtain a representation - basically use a new
convention, on which there is currently no consensus. This may or may not be
a fatal flaw, depending on application requirements.)

If you want something that seems to be accepted and may get traction in the
near future, and works equally with 20x and 30x responses for information
resources, use Link:  The use I had imagined for Link: was not to directly
give metadata details such as dc:creator in Link: response headers, but
rather to do something 303-like and have a single Link: header giving the
location of a metadata record.

If you want to avoid the extra round trip, you cannot use HTTP GET, period.
Metadata services and protocols abound, but the only such protocols I'm
familiar with that are deployed fairly directly using HTTP are URIQA and
ARK. Personally I find URI manipulation (a la ARK) to be very appealing. I
am sorry that I didn't get why this was ruled out; that's probably my fault
for not paying attention, since someone did explain it. I'll look again.

An alternative to MGET is PROPFIND, which I haven't investigated. PROPFIND
might have the advantage of being able to leverage existing DAV protocol
stacks.

There is nothing that says you can't use your own protocol with http: URIs.
The argument is that if you use http:, then you will be "on the web" in a
way that you wouldn't be otherwise. But URIs are just strings after all,
suitable for use as keys into any kind of index, and nothing says that HTTP
is the only way to use them. For example, http: URIs are used with the
SPARQL protocol quite nicely; no one has to do a GET of the URIs in question
in order to get information about their referents.

If you are headed in the direction of using some protocol or protocol
variant with little current deployment anyhow, then there is no reason not
to use URIQA, SPARQL, web services, or anything else. If you already have
your own protocol with implementations, there's no particular reason not to
adapt it to http: URIs. You will be no worse off than you were before, and
the syntactic use of http: gives you the advantage that clients that don't
speak your protocol have a fighting chance of doing something useful with
the URIs.

You have stated the ability to distinguish XRIs from other URIs as a
requirement, and I assume that this having been met an XRI-enabled client
could decide whether to apply whatever special metadata access protocol you
care to use. If you want to be able to somehow exploit clients that are not
currently XRI-enabled then 303 and Link: are probably your best bet in the
short run.

I'm not following the entire discussion in detail and apologize if I have
overlooked some additional requirement that would speak against any of the
above.

I agree with you that a uniform, widely deployed metadata protocol not
requiring that extra round trip and not specific to any particular class of
URIs (such as XRIs or HXRIs) would be a nice thing, but while technically
this is very easy, socially and politically it does not seem to be coming
about. If you want to discuss this, or to design and promote something that
could be used not just for HXRIs but for all URIs (or all http: URIs), I
wouldn't object.

Best
Jonathan

On Sat, Sep 13, 2008 at 1:02 AM, Drummond Reed <drummond.reed@cordance.net>
wrote:

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 


Repeating what I said above: Don't confuse identifier syntax with protocol.
The two are almost orthogonal. You can compare URIQA with some XRI-specific
protocol, and indeed the XRI protocol might come out ahead; I wouldn't argue
one way or the other. But the protocol comparison has no bearing on the
choice of identifier syntax (http: versus xri: scheme) since either protocol
would work equally well with either kind of identifier (although an existing
xri protocol might needs tweaks).

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/