Re: Uniform access to descriptions

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.

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

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

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!

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

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

>
> > 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, 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!

-Eric

Received on Monday, 14 April 2008 20:05:16 UTC