Re: Uniform access to descriptions

On Apr 13, 2008, at 6:22 PM, Eric J. Bowman wrote:

Hi Eric,

I did a careful read through, and I think there are a bunch of issues  
with what you have said, details below.
-Alan

> My thoughts exactly.  URI [a] below identifies "a wiki page" whose  
> topic
> is part of the identifier, and it is a negotiated resource.
I don't know why you put quotes around "a wiki page". You don't say  
what the resource is, but the only interpretation I can make is that  
the resource is a wiki page about topic. If you meant the resource to  
be topic, you should have said that here and explain why [a]  
identifies something other than it denotes.
>
> [a] http://example.org/topic
> [b] http://example.org/topic.html
> [c] http://example.org/topic.xhtml
> [d] http://example.org/topic.rdf
>
> Client dereferences [a], preferring text/html. Response to [a] is 200
> OK, Content-Location [b].  Client dereferences [a] preferring
> application/xhtml+xml.  Response to [a] is 200 OK, Content-Location
> [c].  Thus, it may be inferred from the response codes that [b] and  
> [c]
> identify equivalent representations, or variants, of the resource
> identified by [a], "topic".
You implied that the URI [a] identifies a wiki page about topic. If  
you want to have the resource be an arbitrary topic, you have to  
handle the case where the server should not return 200 because the  
topic is some person.
> Also, [b] and [c] are not representations of the concept, "a wiki  
> page".
Why would they be. But they should be representations of that  
specific wiki page.
> Client dereferences [a], preferring application/rdf+xml.  Response to
> [a] is 200 OK, Content-Location [d].  Thus, it may be inferred that  
> [d]
> is also a variant of the resource identified by [a], "topic".  This
> works perfectly well, if in fact [d] is an RDF representation of
> "topic"
No - representation of a wiki page about topic according to what you  
implied above.
> and not a description of resource [a] as "a wiki page".
> However, what if topic.rdf contains only the assertion that [a] "is a"
> "wiki page", which *is* a description of resource [a]?
OK - this makes me feel certain that you mean the resource is a wiki  
page. Do you see how this doesn't match what you said above: "resource
identified by [a], "topic".?
> Client dereferences [a], preferring application/rdf+xml.  Response to
> [a] is 303 See Other, Location [d].  This clearly means that no RDF
> variant is available,
No RDF variant is available now, from the server handling your  
request. You could go back later and it could respond with a 200.
> however, the client _may_ be interested in a
> _related_ resource of the preferred type.  Client dereferences [d],
> response is 200 OK.  Clearly, dereferencing [d] has not returned a
> representation of the resource identified by [a].
You don't know that. At this point all you know it is that it is  
related. [d] could certainly be related to the resource identified by  
[a] by being a representation of it.
> The client parses
> topic.rdf, which describes [a] as a type of resource known as "a wiki
> page". Thus, [d] is a representation of a description of "a wiki page"
i.e. metadata about [a]
> and not a representation of "topic" or even a description of "topic".
Ok. Not sure why you say this. It would be reasonable for [d] to be a  
representation of anything related to the wiki page.
> Resource [d] can be said to describe resource [a], but it is clearly
> not a representation of the resource identified by [a].
Not entirely clear. If, on the wiki page it says that it is a wiki  
page (as most wiki pages do), then it might be construed as self- 
describing, and so it could be a representation of [a], as long as  
everything described about the page is also said on the page.
> Under "true conneg", if [d] is not considered a variant of the  
> resource
> identified by [a], and a client dereferences [a] but only Accepts
> application/rdf +xml, then a 400 Bad Request would normally be issued.
Not sure how you gauge "normally", I don't think I've ever seen a 400  
issued, personally. Usually the server returns something I didn't ask  
for if it doesn't have what I asked for.
If [d] isn't a variant of <[a]> the server wouldn't know anything  
about it. AFAIK, returning see other in this case is perfectly fine.  
Why wouldn't it be?
> But, if [d] exists and is a *description* of the resource  
> identified by
> [a], why return an error message for [a] when we could return "See
> Other"? This approach breaks nothing, far as I can tell. The corollary
> here, is if a client dereferences [a] but only Accepts text/css, the
> server *could* 303-redirect the request to a shared CSS file.  This
> would be of absolutely no use, of course, but it wouldn't be  
> invalid to
> do it in terms of Web architecture.
>
> -Eric
>