Re: Uniform access to descriptions

Eric J. Bowman wrote:
> Pat Hayes wrote:
>   
>> Its not a RE invention. Nothing about the current Web changes at all: 
>> it allows for a new way of using some existing Web technology, is 
>> all. This way is rational and seems to conform to the current 
>> architecture, provided we are willing to think a little outside of 
>> our current box. And this might come as news to non-semantic Web 
>> mavens, but wa are already outside that box. We've been outside it 
>> ever since the TAG insisted that URIs can identify non-information 
>> things.
>>
>> In fact, if we were to agree on some simple protocols for content
>> negotiation which themselves referred to http codes, it could provide
>> a uniform mechanism for implementing the http-range decision.
>>
>>     
>
> My thoughts exactly.  URI [a] below identifies "a wiki page" whose topic
> is part of the identifier, and it is a negotiated resource.
>
> [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".  Also, [b] and [c] are not representations
> of the concept, "a 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" 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]?
>   
All of them are /descriptions/.  I failed to follow what is the 
difference between /representation/ vs. /description/. In fact, I 
wouldn't prefer to give [b,c,d] a different URI.  I.e., there is no 
Content-Location.  And I do have a concrete use case described at 
http://dfdf.inesc-id.pt/tr/web-arch, where alternative location is not 
preferred. 
> 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, 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]. 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"
> and not a representation of "topic" or even a description of "topic".
> Resource [d] can be said to describe resource [a], but it is clearly
> not a representation of the resource identified by [a].
>
> 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.
> 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.
>   
I don't follow here.  If you are the resource owner of [a-d], don't you 
know that [b-d] describes [a]?  And why do you waste another round trip 
to 303 (or 400)?  Sure, it doesn't break anything. But what do you 
gain?  (I am talking in strict sense, I understand that you may want to 
do that due to saving your development effort).

Regard,

Xiaoshu

Received on Sunday, 13 April 2008 22:54:38 UTC