Re: Uniform access to descriptions

Alan Ruttenberg wrote:
> 
> > 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.
>

OK, point taken, but I don't understand you when you say, "explain why
[a] identifies something other than it denotes" because I'm not sure
what "denotes" means, I think "identifies" and "describes" are
appropriate terms.  My position is that [a] may be *described* as
something other than what it *represents*, and I believe this could
apply to any Web resource.  Yes, the resource is a wiki page about
topic, sorry if that wasn't clear.

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

Sorry, but wouldn't the topic be *about* some person, and not *a*
person?  Plenty of examples of wiki pages exist where the topic is
about a person, and I don't see what's wrong with returning 200 OK in
such case.

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

Right, why would they be?  That's the point, "a wiki page" is a
description of the resource, which has absolutely no relevance to the
representations of that resource.  Those representations are of that
specific wiki page, "topic".

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

Yes, I'm giving an example, I didn't think it necessary to word that
as, "This works perfectly well, if in fact [d] is an RDF representation
of the wiki page [a] which represents the concept 'topic' as described
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".?
>

The resource identified by [a], "topic", has representations of the
concept of "topic".  If "topic" is replaced by "football", what does
the fact that this resource is a wiki page have to do with the concept
of "football"?  The resource *is* a wiki page, but so are many other
resources on a wiki site, so "a wiki page" is a resource description,
not a resource representation.  The resource in my example is a wiki
page about "topic", the "topic" is not "a wiki page", again sorry if
that wasn't clear.

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

Yes, it could, I didn't realize I was required to point out the
obvious in my example, which is only concerned with the resource in the
here and now, not what changes might occur to the resource in the
future and how those might change HTTP response codes.  Are future
changes to the resource really relevant to the discussion here?  There
is no implied permanence in a 303 response.

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

If [d] is a representation of [a], then it would be served with a 200
OK, not a 303 See Other in my example.

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

I call it a description of [a] and not metadata about [a] (although that
term certainly applies) because I wanted to avoid confusion between
inline metadata within representations of [a], and out-of-band metadata
which describes the type of resource [a] is.

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

Well, I thought I'd use [d] instead of creating [e] and calling it
wiki.rdf although I see now that I probably should have.  Many different
wiki pages can point to wiki.rdf as a description of their resource
type, wiki.rdf in such case wouldn't be a representation of any of them.

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

Yes, wiki pages say they are wiki pages in a human-readable fashion.
I'm assuming an ontology which formally describes "a wiki page" in a
machine-readable fashion, perhaps with attributes like "locked",
without speculating about how such data would be used.

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

Usually because Accept headers contain '*/*' as a fallback, which means
the server can serve up anything it has.  If a client only Accepts
'text/css' and no such variant exists, I believe it is incorrect to
serve anything but an error message or a redirect.  If no Accept header
is sent, the server SHOULD respond with 300 Multiple Choices, but I've
never seen this implemented.

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

Why are you asking me "Why wouldn't it be?"  That's exactly what I
described, returning 303 See Other if [d] isn't a variant of [a].

-Eric

Received on Monday, 14 April 2008 00:35:26 UTC