Re: Uniform access to descriptions

Eric J. Bowman wrote:
> Xiaoshu Wang wrote:
>   
>>   
>> 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?
>>
>>     
>
> Why would you want to prevent people from doing that?  Does it violate
> a spec?  Does it cause harm?  You really must learn to accept that
> there are many different ways of doing things on the Web.  If I have
> multiple RDF files describing an HTML document, then yes, I would use
> multiple <link/> tags to connect them.  If my document were raw text, I
> would need the HTTP Link header to do so.
>
>   
>> 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.
>>
>>     
>
> Huh?  Yes, I could do it your way, except I'm not, I'm doing it my
> way.  There is nothing "semantically unclear" about linking an HTML
> document to more than one RDF file, nor is the desire to do this
> something which should lead me to define my own MIME type -- which
> would be mud, semantically, since nobody else would have ever heard of
> it.
>   
It is you who said that Conneg can NOT. Not me.  I never said LINK 
cannot.  I simply telling it is NOT NECESSARY because there are other 
concerns - the principle of orthogonal specification.
>> 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.
>>
>>     
>
> Please stop it, Xiaoshu.  Look up the term "ad hominem" and then
> re-read your responses to others' comments, it is hard to find a
> message from you that doesn't take a shot at the person you are
> debating. It's OK to think outside the box, but it is not OK if your
> solution violates RFC 2616.  BTW, you're the first person who's ever
> accused me of thinking inside the box, particularly where HTTP is
> concerned.  Does your ad-hominem insult add to this debate?  No, it
> merely convinces others that you cannot make your point on a technical
> basis.
>   
If you think that I have insulted you.  I apologize because that is 
never my intension.  But let be honest, if you admit I did tell you a 
solution, regardless if it fits your preference, then, did you really 
think it out of your box.  If you had, why you said Conneg CAN NOT?

In fact, Conneg didn't violate RFC 2616.  Using LINK does because it is 
not in it.  It was in previous spec but that doesn't mean it is in the 
current draft. 
>> 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.
>>
>>     
>
> Is it?  The client wanted an RDF document, I don't recall there being
> any way for a client to state that it only wants a variant
> representation and does not want to be redirected to a related
> resource.  It is not possible to know EXACTLY what the client wants if
> it's asking for only application/rdf+xml because that might mean a
> representation in RDF format, or it might mean a standalone RDF file
> that describes the requested resource, because we're dealing with RDF
> here, not HTML.  In the end, like I said, [d] must be parsed -- so [d]
> should contain an assertion describing [a].
>   
If GET x ACCEPT application/rdf+xml is not clear, I don't know what it 
is clear.  Again, I never said that you CAN NOT redirect.  Check all my 
arguments against LINK or your suggestion, did I said you CANNOT do 
that. Isn't you who have repeated said that something CANNOT be done.  
My point of view is always that you CAN DO without LINK, without 
worrying httpRange-14.

> I do not see how 303-redirecting such a request to a search engine is
> relevant, or anywhere near what the client requested, or how that would
> be more appropriate.  The client requests an RDF variant, or lacking
> that, an RDF document related to the requested resource.  I fail to
> see how, if either said variant or externally-linked document exists,
> it would be in any way appropriate to respond with a search interface
> written in RDF.
>
>   
>> What do we call this in real life?
>>
>>     
>
> A strawman argument.  Please, no strawmen!
>   
But, sometimes we do need that to see some seemingly minor thing's 
higher significance. This is part of scientific investigation: to 
systematically compare things of similar nature. This is how we progress 
our understanding of reality. 

>> 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.
>>
>>     
>
> Stop with the FUD about how the sky will fall due to 303 redirection.
> I don't see any unnecessary round-trips, and certainly not with every
> request.  If an RDF variant is returned using conneg, fine.  If a 303
> redirect to an RDF document is returned, well, that's one redirect --
> from there I would assume an RDF client could browse the entire RDF
> graph.  The 303 aids *discovery* of RDF, it is hardly required on every
> request.
>   
Isn't it httpRange-14 that have injected FUD into the web.  Otherwise, 
why the httpRedirect-57? And some other arguments in the issues, such as 
like version document.  I am simply trying to do the opposite and 
telling people to be free of that httpRange-14 FUD.  (I don't know what 
FUD is.  My definition is through looking up wikipedia.)

For the FUD you referred, it is not that I try to show that I have a 
higher moral ground.  Engineer wise, I took Occum's razor seriously so I 
will always take the simplest approach that I can think of.  Science and 
social wise, I do believe we all bear certain responsibility to 
community and society as a whole.

>> I honestly do NOT understand - What is SO DEAR in there that TAG is 
>> trying to hold up?
>>
>>     
>
> Again, Xiaoshu, please check your attitude at the door.  You aren't
> going to get very far by implying that the TAG has based its decision
> on sentimental rather than technical reasons.  It indicates a closed
> mind on the subject, perhaps that's why you're not understanding it.
>   
I indeed cannot understand it from my rather closed mind.  If you can, 
argue it from a scientific point of view.

Emotion is an evoked feeling, attitude is one of them.  Whether I have 
an "ad hominem" or not does not entirely depend on what I said.  It also 
depends on how the receivers take it.  I may not appear to you or others 
as a polite, articulate, or diplomatic person.  But that has nothing to 
do with what I tried to argue.

Consider, you told me that I am the first one to say that you think 
inside your box. But seriously, don't you think that you indeed did 
that?  I am perhaps the first person to say that.  And I believe I won't 
be the last one to say that too.  You take criticism too personally.  So 
what? - if we all think in the box once in a while, because we are all 
humans and to be flawed is only natural.  I carry a lot of flaws as what 
you suggested.  But if you assume that I didn't have bad intension and 
that I have an attitude as a natural consequence of me being human, how 
are you going to feel about my "ad hominem".
>>> 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?
>>
>> 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?
>>
>>     
>
> There you go again, accusing me of making assumptions, or not knowing
> what I'm talking about, or haven't read the thread, or I'm trying to
> save my project, etc.  These retorts do not help your case, and they
> certainly have no place in a technical debate.  If you are using
> conneg, and you have variants to serve based on the Accept header, and
> you send Vary: Accept but *fail* to send Content-Location, then the
> only thing you're caching is the last variant requested -- let's say a
> client Accepts application/xhtml+xml, and you serve an XHTML variant.
> The next client, encountering the same intermediary cache as the last
> one, Accepts text/html -- the cache will respond with the XHTML variant
> it cached in response to the last request, without Content-Location
> that Vary header just isn't going to do the trick.
>   
Eric, I have repeated many times that I didn't say Location-Header is 
not useful.  What I was trying to say is that I have a specific use case 
that doesn't desire Location-Header. I am simply illustrating the 
possibility of CAN do attitude.  I don't implement server, at least not 
right now.   Do you trust me that I can implement some sort of cache 
solution, it is engineering at last, right?  It may do something 
different than the HTTP protocol, which I don't have time to read its 
caching mechanism, but my application will deal with specific client so 
if I need it I can do it. 
>> 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?
>>
>>     
>
> Again with the ad-hominem shot at anyone who fails to see your point.
> This is going to convince others of your position, how, exactly?  You
> accuse me of "judging you" when nothing could be further from the
> truth, and pile on to that by accusing me of blindly judging others --
> would you happen to have a reference to any post where I might have
> done that, or are you just making that up to insult me for not
> agreeing with you?  You are walking a thin line between participation
> and trolling.  If you don't want people to think you might be trolling,
> then STOP with the bullshit, please.
>
> Xiaoshu, two cases- the RDF stuff and caching - really tells me that 
> you are locked into your way of thinking with a mind so closed that you
> refuse to see the errors you are making and nobody can tell you any
> different.  I believe you are the one with predefined boundaries,
> unfortunately they have no relation to RFC 2616.  See?  We can play the
> dozens back and forth all day.  But, it HAS NO PLACE in a technical
> discussion.  Please!
>   
My position is, in fact, very simple - that is: the current web is fine 
and can work without much extension.  I am simply trying to tell people 
that we can work with what we already had. I hold - in fact - a positive 
attitude toward the web.  It is an engineering project at last, we can 
do a lot of meaningful things by opening our mind.  But it is you that 
constantly told me that you CANNOT do this and CANNOT do that.  I have 
never said the same to you.  I have always said that you sure can do it 
in the old way, but you don't have to.  To use Tim's argument to support 
mime, that is why should the concept of the web has to be limited by the 
concept of IP/TCP's "packet', then why should the concept in the new 
semantic web has to be limited by the concept of pre-semantic web?

Sure, we both have a box, mime is a technical one, yours is a conceptual 
one.  Do you agree?  No, I guess not. So, sorry, you don't have a box.  
But I do have one - that is the web we have.  I tried to expand my 
conceptual box so I can do more things for me with what we have. Is that 
fair?

(For all those *insult*, *attitude*, *ad hominem* that I have put on you 
or other people. I am sorry, O.K?    But can you check those for me at 
your door, please?  I am sometimes too self-centered or self-obsessed so 
I may not be able to be aware any of that.  But I can assure you that 
harming other person's feeling is never my intension.)

Xiaoshu

Received on Monday, 14 April 2008 23:12:58 UTC