Re: Resource-Type Revisited (httpRange-14)

On tis, 2008-01-08 at 11:40 +0000, Sean B. Palmer wrote: 
> On Jan 7, 2008 2:13 PM, Mikael Nilsson <mikael@nilsson.name> wrote:
> 
> > Depending on the request, a server may legitimately 303-redirect to
> > completely different IRs. The semantics of 303 is so weak that this is
> > not meaningful.
> 
> Well it has to be information about the resource you requested at
> first,

I disagree - and this is my main issue with 303. It just refers to
another resource (or several resources, using conditional redirects)
somehow related to the original. If you can point to anywhere where I
can find an authoritative definition of the target resource of a 303
redirect that somehow limits what can be put there, I'd be happy.  

There might be metadata about the original resource there, but there is
nothing requiring that all possible 303s from a single URI all have the
"same meaning".

> so I don't think it's much different from the semantics of the
> resource <-> representation association.

I think it's *very* much different. "all essential characteristics" vs.
"some related information".

> 
> In other words, this sort of thing would be okay:
> 
> 7th January: <uri> -303-> [ dc:title "About My Book, 2nd edition" ] .
> 8th January: <uri> -303-> [ dc:title "About My Book, 3nd edition" ] .
> 
> Which means that you take the most generic aspect when titling:
> 
> [ :from <uri>; dc:title "About My Book" ] .

But how do you know what this generic aspect is, in the presence of
conditional redirects?

<uri> -303-> [ dc:title "FOAF RDF file describing me" ] . (when Accept: application/rdf+xml)
<uri> -303-> [ dc:title "My homepage" ] .                 (when Accept: text/html)

seems perfectly legitimate to me.


> 
> > Second - what stops you from introducing this property if *you* find
> > it useful? It seems we're mixing two issues here
> 
> Not mixing the issues. I just used this to explain the context in
> which I was thinking about Resource-Type. You can ignore it safely if
> you understand the issues without it.

Ok, understood. :-)


> > "InformationResource: no" says something about the resource
> > that we don't really have any use for.
> 
> What useful thing does Description-ID say that "InformationResource:
> no" doesn't? What about Resource-Type?

All of the require loosening the 200 Ok semantics to no longer mean
"this is a faithful representation of the resource". 

InformationResource: no
~~~~~~~~~~~~~~~~~~~~~~~
Says: whatever this message contains, it certainly is not a faithful
representation of the resource

Description-ID: hepp
~~~~~~~~~~~~~~~~~~~~
Says: This message is not a faithful representation of the resource. It
*does* contain a description about the resource, and that description
has the ID (=relative URI?) "hepp". Note that this is (IMHO) much
stronger than 303, and thus in this aspect better...

Resource-Type: http://example.org/siteOntology#Site
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Says: This resource is of the
type http://example.org/siteOntology#Site. You'll have to find out for
yourself whether this means that the message contains a faithful
representation of the resource. The problem here is that it says
something about the resource, but *nothing* about the message. Why
should a certain resource type imply anything about the message at hand?
And the whole problem we're trying to solve has to do with what we can
assume about the message.

/Mikael


> 
-- 
<mikael@nilsson.name>

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

Received on Tuesday, 8 January 2008 13:10:47 UTC