httpRange-14 - what are the use-cases?

It seems to me the discussion is getting away from being very practical,
and we *are* trying to solve an engineering problem here. Sean's
message 

http://lists.w3.org/Archives/Public/www-tag/2007Dec/0013.html

got me thinking about what the *exact* use-cases are for 303s etc.
Finding the right use-cases would help answer whether a header-based
approach would work, whether 302 or 303 matters, and whether we need
anything at all.

To me, the basic use-case that we want to address is the one below.
PLEASE, be gentle when reading this. There are *many* steps involved,
and a lot of assumptions. But we need to show *exacly* what happens. If
you spot errors, please comment.

USE-CASE A: Annotating something
================================

Alice finds a link to the URI http://en.wikipedia.org/wiki/Paris 

Curious about what is there, she clicks, and a document is displayed in
her browser. She reads the text, and finds it interesting, but not
appropriate for making her travel plans to Paris.

So she takes the URI in the location bar into her annotation system (be
it delicious, annotea or any RDF store), and adds a triple:

<X> ex:annotation "Not suitable for making travel plans. Also, very bad
grammar and difficult to read."

(the value of X depends on the resolution chosen, see below-9

Bob, using an RDF harvester to find information about Paris, finds in
his RDF dataset that

http://dbpedia.org/resource/Paris

is of type City and seems to denote Paris. So he tries to find triples
originating from this URI.

What we don't want to happen
============================

In no case do we want Bob to see the triple

<http://dbpedia.org/resource/Paris> ex:annotation "Not suitable for
making travel plans. Also, very bad grammar and difficult to read."

-----------------------------------------------------------------------

So, using this use case, let's see what can happen.

I. Use current httpRange-14 resolution.
http://en.wikipedia.org/wiki/Paris is an information resource
returning 200 Ok, and the HTML returned is a webarch:representation of
the resource. X = http://en.wikipedia.org/wiki/Paris

Alternatively, http://en.wikipedia.org/wiki/Paris 303s to
http://en.wikipedia.org/wiki/Paris-text.html, and Alice ends up using
that URI instead. X = http://en.wikipedia.org/wiki/Paris-text.html

http://dbpedia.org/resource/Paris is a non-IR, returns 303 See Other to
http://dbpedia.org/page/Paris

In no case can we expect to see an owl:sameAs between Paris, the web
page, and Paris, the city. No issues arise. 

II. Allow 200 for non-IRs. 
http://en.wikipedia.org/wiki/Paris can now be used to denote Paris,
the city. It returns 200 Ok, with an xiaoshu:representation of Paris,
i.e. some useful information about Paris. 
X = http://en.wikipedia.org/wiki/Paris

Charlotte has noticed this, and produced the triple

<http://en.wikipedia.org/wiki/Paris>
owl:sameAs <http://dbpedia.org/resource/Paris>

which Bob sees in his harvester. Thus, Bob can smush the two resources,
and ends up with

<http://dbpedia.org/resource/Paris> ex:annotation "Not suitable for
making travel plans. Also, very bad grammar and difficult to read."

and wonder what that has to do with Paris.

What went wrong?

III. The header solution.
http://en.wikipedia.org/wiki/Paris returns 200 Ok, but with a
Description-ID: header. The browser happily displays the page.
Alice goes ahead and annotates, and we end up in case II.
X = http://en.wikipedia.org/wiki/Paris

Alternatively, her RDF software does a HEAD on the URI before adding it,
finds that it's not an information resource, and asks Alice whether she
wanted to annotate Paris, the city, or "Paris", the wiki page (as
returned in the Content-Location header). Alice ends up somewhat
confused, but probably does the right thing, leading to case I, and no
issues.
X = http://en.wikipedia.org/wiki/Paris-text.html

IV. The 302 solution
http://en.wikipedia.org/wiki/Paris denotes Paris, the City, and
returns 302 Found to http://en.wikipedia.org/wiki/Paris-text.html.
That's the URI Alice uses to annotate the resource, as that is what her
browser displays.
X = http://en.wikipedia.org/wiki/Paris-text.html

On the surface, this seems to work.

However, Charlotte, being very observant, reads the HTTP spec and notes
that "The requested resource resides temporarily under a different
URI.", and so adds 

<http://en.wikipedia.org/wiki/Paris> owl:sameAs
<http://en.wikipedia.org/wiki/Paris-text.html>

Back to case II.


------------------------------------------------------------------------

My point
========

The naive reaction to annotate the document one sees on-screen using the
URI one sees in the location bar is highly important to preserve.

This works when the message returned contains a webarch:representation
of the resource, that is, a "faithful rendering" of the resource, so
that all possible webarch:representations have essentially the same
information content. Then any annotation Alice can make will be correct.

It does *not* work when Alice sees a message that is not a faithful
webarch:representation of the resource. THAT, IMHO, is the point of
303s.


/Mikael

-- 
<mikael@nilsson.name>

Plus ça change, plus c'est la même chose

Received on Wednesday, 5 December 2007 10:38:50 UTC