Re: Uniform access to descriptions

Eric J. Bowman wrote:
> Xiaoshu Wang wrote:
>   
>>> I have read your references.  I disagree with your position in its
>>> particulars, but in a larger sense I agree with the notion of using
>>> content negotiation.  I have posted how I believe content
>>> negotiation and 303 redirects may be used more properly for your
>>> ends, than the method you have suggested.
>>>   
>>>       
>> First, I do not think 303 solve my particular use case. 
>>
>>     
>
> No, they don't.  Furthermore, conneg does not solve the problem of
> attaching multiple RDF files to a resource, which is easy to do with
> HTTP Link headers, as more than one is allowed.  I support httpRange-
> 14, I did not present my example as a solution to your problem but as a
> response to what Pat said:
>   
First, why do you want to do that, i.e., to bind multiple RDF files with 
one URI?  Do you do the same thing with regular HTML file?

Second, who said you cannot?  (a) You can always use one front RDF file 
with multiple imports. (b) If you want meta-meta kind of relationship, 
you can always define a new MIME-type and bind however many RDF files to 
the same URI, which is, in fact, much more semantically clear.

You think that is because you tries to fix your mind into whatever the 
current architecture tells you, which, of course, prevent you from 
thinking out of the box.
> "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."
>
>   
>> Second, I still could not rational your example.  If you know the 
>> relationship between [a-d], and you also understand what a client 
>> request, I don't know why you have to use 303/400 but 200 to serve
>> your client's request.  On the other hand, if you don't know the 
>> /representation/describes relationship of [a-d], how can you serve it
>> later?
>>
>>     
>
> It implements a "yes-no-maybe" check at the protocol layer.  The client
> wants to know if an RDF document is available for a given URI, so the
> client dereferences the URI with Accept: application/rdf+xml.
>
> 200 = yes
> 406 = no
> 303 = maybe
>
> I think it's logical for a client to infer that the target of such a
> 303 redirect would have been served using a 200 response, if it were
> indeed a representation of the request URI.  So the 303 means, maybe
> there *is* an RDF document that relates to the request, but the client
> won't be able to determine that without parsing the target of the 303.
> The 303 response can include one or more Link headers, if more than one
> RDF document applies to the originally-dereferenced URI.
>   
Isn't your client's intension VERY clear?  And didn't you know EXACTLY 
what they want?  Who said /maybe/? Isn't you?  And you do you - in the 
end - knows if [d] is an RDF description of [a] or not?  If you 303 to a 
search engine, that is the more appropriate response.

I think now (I guess) I understand what you tried to say: which is, O.K. 
we can still work within the framework of the current architecture 
prescribes.

Let's me give you a *real world* example that you may (or have already) 
encounter in the real world. Say, you go to a post office to get a 
package.  A lady named Jane happily greets you. You gives her your 
package slip. She looked at it and then say "Go out and come back 
again", you don't know why but nevertheless follow her instruction and 
come back.  She then took your slip and give you the package. 

What does that make you feel?  Wouldn't you feel compelled to ask her: 
why the hell you want me to go out and come back again? Her reply would 
be - and you have argued for her - "because I have to follow the 
*proper* procedure!"

What do we call this in real life?

And at what cause? All these unnecessary round-trip?  If we indeed in 
the future goes full semantic web.  Then, for every URI, there is 
unnecessary round-trip and a waste of bandwidth.  And now we are talking 
about global warming, energy conservation, And who is doing whom a 
disservice.

I honestly do NOT understand - What is SO DEAR in there that TAG is 
trying to hold up?
>>> Which does not change the fact that you're using a fringe case to
>>> make your point, and said fringe case goes against proper Web
>>> architecture, which sorta means referring to Web architecture
>>> regardless of the delicate sensibilities of anyone on this list.
>>>   
>>>       
>> Well, you call it a fringe case because you couldn't define it.
>> Which one is a more proper architecture, the one with fewer fringe
>> case or the one with more?  I think the theory of relativity is a
>> *fringe* case w.r.t. classic physics.  And you can say the latter is
>> the proper physics...what can I say?
>>
>>     
>
> No strawmen, please.  I consider any HTTP implementation which
> deliberately disables caching, in cases where caching is clearly still
> desirable (as in your example), by going against a SHOULD in the spec,
> etc. as a fringe case.  
Think again?  You supposed caching is based on the assumption they never 
cached against /Accept/.  I don't think I have to say the rest.  
Thinking more, please, don't make any assumption too quick, O.K?
> A conneg application which chooses not to send
> Content-Location headers because caching is not desirable, is quite a
> different thing from a conneg application which CANNOT send Content-
> Location headers even when caching _would_ be desirable.  Again, my
> solution to your use case is to refactor the application such that it
> conforms with RFC 2616's intent, even if it does conform to the letter
> of the spec as-is.
>   
First, I have a specific use case that I don't desire Content-Location, 
I didn't deny other people from using Content-Location. 

Second, the absence of Content-Location doesn't disable any potential 
caching implementation.  What is the difference between caching 
URI+Accept and caching URI+Content-Location?

Eric, two cases - the RDF stuff and caching - really tells me that you 
have a predefined boundaries that you want to work with.  This is your 
choice, which I have no right to judge.  But please don't use your 
predefined boundary to blindly judge me or others, O.K?

Xiaoshu

Received on Monday, 14 April 2008 09:56:22 UTC