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.
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.
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?

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 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.

Test case:

  GET /timbl/email
     ->
  302 Found
  Location: mailto:timbl@w3.org

  Conclusion:  /timbl/email identifies a mailbox.

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??

> 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.

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, 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.
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

Tim

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

Received on Wednesday, 5 December 2007 00:54:03 UTC