Re: Alternative to 303 response: Description-ID: header

>On 2007-12 -04, at 11:55, Sean B. Palmer wrote:
>
>>
>>On Dec 3, 2007 8:39 PM, David Booth <dbooth@hp.com> wrote:
>>
>>>I think the Semantic Web's use of URIs and HTTP is *layered* on
>>>top of the old-fashioned Web's use of URIs and HTTP.
>>
>>If that were so, we could use any HTTP URI to refer to any resource if
>>we wanted to. The only reason I'm aware that we cannot is because of
>>the interpretation of the "network resources" passage in RFC 2616.
>
>No, it is because we are already using the URI of a web page to 
>identify the web page for many things.

You are talking past one another. Tim, you are saying "identifies"; 
Sean is saying "refers to". These are not the same, and pretending 
that they are only spreads confusion and mutual incomprehension. Sean 
is right, in that a priori, as it were, a single URI might identify 
one thing (in the HTTP sense, the sense used throughout the 
pre-semantic Web) and refer to another, so it does not follow from 
the URI's being used to identify X that it must also refer to X. But 
if one phrases the http-range-14 decision as "When HTTP returns a 200 
code, then the URI must refer to (aka denote) what it has identified" 
- which is, I suggest, the true nugget or core of that decision, from 
which all else follows - then what you are saying connects with what 
Sean is saying, and responds to his objection quite conclusively.

>It is layered *non-destructively* on top of HTTP.
>
>>I've never seen a compelling reason why we must disambiguate between
>>information resources and non-information resources using HTTP
>>responses. What are the intrinsic properties of information resources
>>that are so important that all Semantic Web HTTP user-agents *must* be
>>told whether a resource is an information resource or not?
>
>Sean, you are looking at this upside-down, I think.
>It isn't what it is, primarily, its what you have just leaned about it.
>If you have learned the contents of it then you can display it, etc. 
>Things we can display, etc, we call IRs just for a term.

<aside> Well, to be picky for a second, that isn't strictly true. 
What I can display is the tag:representation of the IR, which is all 
I can ever get a hold of in any case. For example, 
http://www.paris-live.com/ gives me a view of the Eiffel tower, but I 
can't display the actual webcam. </aside>
>
>The critical thing is not trying to define that term, it is 
>\understanding HTTP when it says
>"Here is what that says".
>Thats the architecture.
>
>The important thing is that the HTTP response is common and shared.
>The 200 status indicates that the response is a tag:representation 
>of the resource,
>or in common parlance the content of the document you asked for.
>
>Suppose you ask me what the Jaberwocky is, having no clue.
>If I say, well, Sean, here is some beer you can keep in it", then 
>you might assume it is a pot of some kind.
>If I say, "It starts 'Twa's brillig and the slithy toves" you then 
>conclude it is a document of some kind, as I can tell you what it 
>says.
>
>HTTP was originally designed for delivering the contents (in some 
>form) of document,
>and so when it gives you the document contents (loosely), isn't it 
>reasonable to conclude that
>it is a document?

That WHAT is a document? What the URI identifies, or what it denotes? 
As you say, http was designed for delivering things that have been 
identified. It wasn't designed for referring to things AT ALL. In 
fact, ideas of reference  and denotation come from a completely 
different space which has absolutely nothing to do with anything in 
the pre-semantic Web architecture. Until someone authoritatively 
states a connection between them, there isn't one.

All of your Jabberwocky example is about reference/denotation. BUt 
HTTP is about locating and delivering the content of documents. These 
are different worlds. You have to state clearly the intended 
relationship between them, rather than take it for granted. Its not 
obvious or necessary: it has to be spelled out.

>
>A 303 means "Try this other document for more information".
>That doesn't imply anything about the original thing.
>
>A 302 says "Here is another URI for the same thing

Same thing or same document? Identification or reference? It all 
turns on exactly which you mean.

>you should use for now".
>It doesn't tell you what the thing is. But when you find out what the
>thing <b> is, then you know <a> is the same sort of thing.

Why? If this is all about documents, then an RDF description of me 
and a JPEG picture of me are very different kinds of document but 
both about the same kind of thing (in fact, the very same thing).

>Test case:
>
>  GET /timbl/email
>     ->
>  302 Found
>  Location: mailto:timbl@w3.org
>
>  Conclusion:  /timbl/email identifies a mailbox.

? Why not have the conclusion: to find out what /timbl/email refers 
to, send Tim an email and ask him.

>But more mainstream, if A 302s to something which 200s then it A 
>identifies a web page.  That is coded in tabulator now, so it knows 
>for example to give you the option of displaying the thing in an 
>inline frame.
>
>>Why can't that information just be garnered from whatever RDF the
>>Semantic Web agent has to hand? That's all it can do for every single
>>other property of a resource.
>
>What would you do? Have every web browser stop rendering web pages until
>it can fins an RDF statement to the fact that it really *is* a web page??

No. To speak for Sean here for a second. URIs clearly identify Web 
pages, and will continue to do so; but we aren't here talking about 
identification, but about reference. Hence, that says nothing at all 
about what the URIs denote (refer to). Just because it identifies a 
Web page doesn't mean that it must denote that Web page. So unless 
there is some actual assertion accessible about what it denotes, then 
you know nothing about what it denotes. (I know that httpRange-14 is 
supposed to clarify this, but in fact is isn't usually phrased in a 
way which does clarify it.)

>>Generally if I request an HTTP URI and it sends me back some RDF
>>giving properties of the resource denoted by the URI, I take that as
>>authoritative. Why do we need this weird implicit and useless classing
>>via HTTP responses?
>
>That is a different design.
>It doesn't give us back a URI for the RDF in question.
>I am used to having a URI which I can send to seomone and say "read 
>that" and I know their world view will be enhanced by the 
>information I just received.

Thats exactly what Sean is proposing also. That criterion doesn't 
distinguish your positions.

>You could make a SPTP, which works as you say.
>
>I would not be able to use it for a plan web page, as the protocol 
>says I will get back RDF about the thing I asked for

That is a non-sequiteur, given Sean's assumption that reference and 
identification are independent of one another. Which, to repeat, is 
indeed the case, until someone clearly says the contrary.

>, so if I want a web page the RDF had better contains some things in 
>the RDF to tell me how to display it. But that would work.
>
>I think though the architecture in which existing URIs on the web 
>identify the web pages is good and useful.

Of course. Nobody is arguing against that. The issue is not what they 
IDENTIFY, but what they DENOTE (aka refer to).

>Maybe we can get the best of both worlds.
>
>I did wonder about the following:  in the case when the URI is not 
>of document, when currently we use 303,
>then the  server can return a document *about* it with  an extra 
>header to explain to the browser
>that it is actually giving you a description of it not the content 
>of it.  (Pick a header name)
>
>Description-ID:     kynase/data
>
>This would be used quite like content-location
>
>Content-location:  kynanase/data.n3
>
>which explains conneg has happened and you ended up with this.
>
>I think I have suggested this somewhere else.
>
>Something like, for dc:title
>
>GET  /dc/elements/1.1/title
>->
>200  returning the ontology... look out
>Description-ID:   /dc/elements/1.1/
>Content-location: /dc/elements/1.1/dces.rdf
>
>It has the advantage that old browsers will just deliver HTML happily.
>
>GET  /dc/elements/1.1/title
>->
>200  returning the related reading material not the contents
>Description-ID:   /dc/elements/1.1/
>Content-location: /dc/elements/1.1/dces.html
>
>The disadvantage is that if you ignore the header you get a semantic 
>inconsistency,
>but well, those people who are concerned about such things could

...get knotted?

Pat

>
>Tim
>
>>
>>
>>--
>>Sean B. Palmer, http://inamidst.com/sbp/


-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Wednesday, 5 December 2007 21:45:10 UTC