Re: Question on the boundaries of content negotiation in the context of the Web of Data

Williams, Stuart (HP Labs, Bristol) wrote:
> Hello Xiaoshu,
>
>   
>> Of course. But in Michael's example, the conneg is conducted on the
>> "http://sw-app.org/sandbox/house".
>>     
>
> Opps... yes.... /me backtracks and fills on the missing "sandbox" and mentally does so for all preceding posts...
>
>   
>> -----Original Message-----
>> From: Xiaoshu Wang [mailto:wangxiao@musc.edu]
>> Sent: 13 February 2009 12:55
>> To: Williams, Stuart (HP Labs, Bristol)
>> Cc: Michael Hausenblas; www-tag@w3.org
>> Subject: Re: Question on the boundaries of content
>> negotiation in the context of the Web of Data
>>
>> Williams, Stuart (HP Labs, Bristol) wrote:
>>     
>>> Hello Xiaoshu
>>>
>>>       
>>>> -----Original Message-----
>>>> From: Xiaoshu Wang [mailto:wangxiao@musc.edu]
>>>> Sent: 12 February 2009 20:15
>>>> To: Williams, Stuart (HP Labs, Bristol)
>>>> Cc: Michael Hausenblas; www-tag@w3.org
>>>> Subject: Re: Question on the boundaries of content
>>>> negotiation in the context of the Web of Data
>>>>
>>>> Williams, Stuart (HP Labs, Bristol) wrote:
>>>>
>>>>         
> <snip/>
>
>   
>>> wrt: "Michael really wants to know: if it is O.K. to use
>>> content negotiation to sever both a png and a ttl as the
>>> representations of the same resource, assuming these two
>>> things do not have canonical URI."
>>>
>>> ...only if they are awww:representations of the same thing
>>> - which in this case they are not - one is an
>>> awww:representation of picture and the other is an
>>> awww:representation of a graph - and as you say "I have never
>>> meant that image/picture and a graph are the same thing.
>>> (That is trivially false)."  So... I think the answer to
>>> Michael's question is clear.
>>>
>>>       
>> Here, the subtle difference arise.  To make things clear, let's use
>> "png", "ttl" to refer the awww:representation and "the:png" and
>> "the:ttl" to their URIs.
>>     
>
> Well... we agreed here and elsewhere that those awww:representations don't have the URIs that you just ascribed to them.
> I also don't know whether you mean to be speaking literally of the URIs or the resources with which they are associated.
>   
Yes, we are fine here.  Not the URI literal, current URI spec don't have 
that capability yet.
>   
>>  Then, my point is: with regard to "the:png" and "the:ttl",
>> "pgn" and "ttl" are representations of different things.
>>     
>
> awww:representations, yes?
>   
Yes.
>   
>> That is obviously true.  But let's assume that "the:png" and "the:ttl"
>> don't exist
>>     
>
> URI don't exist or the things to which they are intended to refer?
>   
Undisclosed as you mentioned later.
> [BTW: I think URI are used links in such away that <uri> pol:represents <pol:thing>]
>   
Well, my thinking is:
<uri> pol:denotes <pol:Thing>.
Dereference a <uri> by a protocol, such as HTTP, gets a 
<pol:Representation>
And <pol:Representation> pol:represents <pol:thing>

If awww:Representation is any different from pol:Representation, it is a 
subsume relation such as this,

And <awww:representation> rdfs:subClassOf <pol:Representation>
>   
>> or instance, we don't have to provide it in the
>> Content-Location when they are served under "the:house" URI).
>>     
>
> Not exist or just undisclosed.
>
>   
>> Then,
>> "png" and "ttl" are awww:representations of "the:house" -- as you said -
>> a set of ephemeral set of bits and some metadata.
>>     
>
> Be careful with the prescription of this particular example in that "the:house" as in "http://sw_app.org/sandbox/house" has never been claimed anywhere as designating a house (conceptual, actual, class or otherwise)- that priviledge was afford to "http://sw_app.org/sandbox/house.ttl#my".
>   
Does it matter with a fragment identifier or not? I don't think so.  All 
URI should work in the same way, fragmented or not.  The difference of a 
fragment URI and a non-fragmented one is the path to the representation 
(either awww or pol one, it doesn't matter).  How we obtain the 
information of something should have nothing to do with the semantics of 
that thing. This is, in fact, the critical mistake of httpRange-14.
> Neither, the PNG serialisation of the image or the ttl serialisation of the graph are claimed as representations of whatever is designated by "http://sw_app.org/sandbox/house.ttl#my". 
I am a bit confused by the wording "Neither".  Do you mean that the PNG 
serialization of the image can NOT be the representation of 
"http://www.sw-app.org/sandbox/house.ttl#my"? Or you mean it can?  I opt 
for the "can" because I don't see any reason for me NOT to accept 
other's claim.  And from the picture, it seems that that image is 
intended for "http://www.sw-app.org/sandbox/house.ttl#my".

> At best one might claim them as equivlent representations of "http://sw_app.org/sandbox/house" but I have no idea what resource Michael intended that to be.
>
>   
>> Please note, now, I
>> am not referring to the awww:representation returned from "the:png" and
>> the "the:ttl" but from "the:house". Can we say "png" and "ttl" are the
>> representations of the same thing - "the:house"?
>>     
>
> See above... the protocol is at least claiming them as representations of whatever is designated by "http://sw_app.org/sandbox/house". The narrative has offered no suggestion so far as to what that might be. I suppose it could be some composite description/depiction of a house - and one could maybe reasonably argue that the two awww:representations were reasonable representations of such composite - but you have started to work hard to create an awkward composite for the purposes of an argument.
>   
Why "the:house" has to be a description/depiction of a house?  If 
"http://www.sw-app.org/sandbox/house#my" denotes the house that someone 
actual lives it and the PNG or ttl serialization of it can NOT be a 
awww:representation of it? It is the "NOT" that should work hard to 
create an awkward argument, as the debate for IR and httpRange-14.  Not 
by me.  My view is always simple, you get a representation, you 
understand its content, and you tries to understand things.
>   
>> If the answer is "yes", then we don't differ in anything. If the answer
>> is "no", then that is where the difference resides.
>>     
>
> Well, in so doing the protocol is making the claim. And in some careful constructed examples the claim might even be reasonably justified - but it is highly likely that the png and ttl serialisations will be awww:representations of different things.  
Does it matter if some representation is "highly likely" be 
awww:representation of different things.  Given the context -- you get 
an awww:representation of a thing denoted by a URI -- what does it has 
to do with the possibilities that the obtained representation might be 
used under other context?  I don't understand.
> But the claim made by the protocol can be inconsistent with 'reality'.
>
> Consider conneg between a .jpeg and .png representations of an image. I think we find something objectionable of the user were presented with a rendering of a dog in one case and a car in another. What resource could that possibly be? Well we could make up a very strange one for which it were reasonable - but on the whole it isn't the sort of thing that happens.
>   
That could be two cases (1) a poor implementation or (2) there does 
exist something like a car-dog. In the first case, can any specification 
prevents people from making mistakes?  In the second case, who are we to 
say something is true or not?  We don't have to believe it but do we 
have the right to say that someone-else shouldn't express his belief ?
> FragId semantics are the other things that has to be coherent across connected representations. RDF representation inherently have a "thing-described-by" indirection - the #frag part is not designating some region within the serialisation (as it does in html) but something described by statements carried in the serialisation. I don't know what #frags are said to refer to for the .png media-type registration.
>   
Every URI (fragmented or not) has "thing-described-by" indirection. Not 
just in RDF.  For instance, http://www.w3.org/TR/webarch/#identification 
doesn't not denote an HTML fragment with an id attribute or name 
"identification".  It denotes the thing/content described by that URI.  
To use the notation that I discussed at 
http://dfdf.inesc-id.pt/tr/uri-issues, the URI -- 
http://www.w3.org/TR/webarch/??application/xhtml+xml#identification -- 
denotes an HTML's element.

Xiaoshu
>   
>>>> The so-called identity crisis is not because there is something called
>>>> Information Resource but because the intention to think that a
>>>> representation is the same as what a URI denote.
>>>>
>>>>         
>>> We (you and I have) been here many times... and I believe
>>> that we (you and I) have consistently agreed that URI refer
>>> to resources and not to the emphmeral awww:representations
>>> returned in response to questions asked of the web. I don't
>>> think that there is anything I have said that can cause you
>>> to think that I am using the URI from Michael's scenario to
>>> refer to awww:representations. I have tried to be careful to
>>> speak of house and images and graphs which are the resources
>>> in this story. I have referred to representations (PNGs and
>>> Turtles), but I have tried to do so with out naming them.
>>>
>>> So... you cast thus as an Identity Crisis - and by the way,
>>> Michael's scenario doesn't delve into information resource or
>>> not - it's about conneg. But I see no crisis here.
>>>
>>> Michael's choice of URI (by accident or design) for the
>>> house means that we really don't have to visit the
>>> httpRange-14 realm - no-one has yet asked what (kind-of)
>>> thing http://sw-app.org/home refers to (and I don't ask that
>>> now) we have:
>>>
>>>     http://sw-app.org/home#my refering to a house
>>>     http://sw-app.org/home.ttl referring to an RDF graph
>>>     http://sw-app.org/home.png referring to an image/picture
>>>       
>                        ^/sandbox
>   
>> Of course. But in Michael's example, the conneg is conducted on the
>> "http://sw-app.org/sandbox/house".
>>     
>
> Opps... yes.... /me backtracks and fills on the missing "sandbox" and mentally does so for all preceding posts...
>
>   
>> The other two URIs does not exist.
>>     
>
> The all worked when I tried them (correctly incanted).
>
>   
>> I think Michael minted the other two URIs for the sake of easy
>> discussion and implementation.  And it is here that the focus of
>> discussion is diverted because (I think) he intended to use the other
>> two URI to refer to the awww:representations.
>>     
>
> Who can say? Michael I guess... but I would state it differently... that he use the other two URI to refer to more specific variant resources that provide a more restrict set of available representations (that preserve some quailty of interest that is established the conneg, be it natural language variant, image resolution, image encoding, serialisation content-type... whatever).
>
>   
>> But the URIs
>> was used for awww:resources.
>>
>> Perhaps, I have assumed too much (about the identity crisis).
>> Here is my inference:  Given a URI, say http://www.w3.org, we can not
>> really say it is a (HTML) web page.  One of its awww:representation is.
>>     
>
> Well it is an HTML serialised awww:representation fo something, ...yes.
>
>   
>> I think, again perhaps over-assummed, the definition of IR is intended
>> to allow people to say "http://www.w3.org" is a web page and httpRange-14 tries
>> to enforce it be saying under which condition that you can say it.
>>     
>
>
>
>   
>> It is the same that we cannot say that "the:png" (the awww:resource) is a
>> PNG image unless there is an assertion to say that one of its
>> representation is a bit-copy of the resource.
>>     
>
> That is why I say only (and then really only informally) that it is an image. I have the same problem speaking of HTML documents (or PDF or Postscript or...) - when what I am speaking of is a resource referred to by a URI, though I will happily speak of an HTML awwww:representation of a resource. But that is largely because of the awkard pun of whether document is being spoken of in a resourceful sense or a (awww:)representational sense. I try to stick with speak of documents in a resourceful sense - and when pressed so to many others, but when speaking causally we often slip to thinking of representation as document and then confusion reigns.
>
>   
>>>> In Michael's case, the
>>>> URI "http://sw-app.org/sandbox/house#my" denotes a house.
>>>> The png and ttl doc is a representation of the house, regardless if the
>>>> latter has canonical URI, such as "http://sw-app.org/sandbox/house.png" or
>>>> "http://sw-app.org/sandbox/house.ttl".  It is the same if the latter
>>>> (the ttl) file is served under the "...png" URI.
>>>>
>>>>         
>>> There is an image and a graph... both, distinct web
>>>       
>> resources, which are pol:representations of a house.
>>     
>>> That does not make either of them awww:representation of
>>>       
>> said house, they are awww:representations respectively of
>> resources that happen to be a graph and an image (that
>> describe or depict a house).
>>     
>>>       
>>>> If "...png" URI denotes an image, it is an image, not a byte-stream
>>>> unless there is an explicit assertion.
>>>>
>>>>         
>>> Yes... have I said anything to the contrary. I don't believe so.
>>>
>>>
>>>       
>>>> The representation of
>>>> an image is a byte-stream.
>>>>
>>>>         
>>> "The awww:representation of ..."
>>>
>>>
>>>       
>>>> A lot of often exampled so-called URI ambiguity are incorrectly argued.
>>>> For instance, to say that, without IR, "a person or
>>>> a molecule" would have a byte-length, etc. is wrong.  It mistakes a
>>>> resource from its representation.
>>>>
>>>>         
>>> Have I made such a mistake in this dicussion? - I don't believe so.
>>> Or are you now introducing rhethorical points making claims that no-one has made?
>>>
>>>       
>> No. But they are often used example argument for the necessity of IR. For "byte-stuff"
>> see: http://lists.w3.org/Archives/Public/www-tag/2009Jan/0135.html
>> For dc:creator see: http://www.w3.org/2001/tag/2009/01/29-minutes.html
>>     
>
> FWIW: I'm trying to stay within the bounds of this thread and not range randomly over the massive corpus of messages in the httpRange-14 permathread.
>
>   
>>>> It is the receiver's fault.  Another
>>>> example, saying w/IO, "a molecule would have a creator" is also not
>>>> ill-founded.  Most time, it is simply its content creator's fault.  If
>>>> they know what their URI should denote, they would not have made such a
>>>> mistake.  On the other hand, how do we know that a molecule is not
>>>> created by someone?
>>>>
>>>>         
>>> I really can't parse this example - specifically the premise ...
>>>
>>>
>>>       
>>>> I did argued the same point over and over again.  But I really cannot
>>>> understand why TAG refuses to accept such a simple fact -  What a URI
>>>> references/denote is not the same thing as what a URI is dereferenced.
>>>> This is what causes the so-called identity issue.
>>>>
>>>>         
>>> If by the above paragraph you mean to say that you believe
>>> that the TAG (and/or individual members of the TAG) do not
>>> accept that URI refer to resources (awww:resources,
>>> pol:Things) as opposed to awww:representations (ephemeral
>>> bits/byte streams and metadata) there of... then I believe
>>> that substantially that is NOT the case.
>>>
>>>       
>> I do believe that TAG accept URI refer to resource.  But I think TAG
>> would also like a portion of the resource (i.e., IR) to be
>> the "same" as awww:representation.
>>     
>
> I don't believe that to be the case - but others must speak for themselves.
>
>   
>> Otherwise, I don't see the need for IR, hence my inability to understand
>> the reluctance to drop the concept.
>>
>> Xiaoshu
>>
>>     
>>> ie. AFAICT you state that the TAG refuses to accept
>>> something that I believe a significant proportion of, if not
>>> the whole, TAG do infact believe and *is* the model presented
>>> in http://www.w3.org/TR/webarch and is specifically
>>> illustrated in the first diagram therein.
>>>
>>>
>>>       
>>>> The practical solution, I think, would not be trying to define what is
>>>> IR (Honestly, I don't think there can ever be).  Rather, it is to find a
>>>> standard way to denote "representation".   Once we know when we are
>>>> working with representation, and when we are working with resource
>>>> (i.e., by way of URI), then all things will be very clear.
>>>>
>>>>         
>>> I'm sorry... but by way of URI we are working with
>>> (referring to) resources (awww:resources, pol:Things).
>>> Agreed, there is no 'standard' way of referring to an
>>> awww:representation. Certainly we can mint URI (if we want
>>> to) to refer to such transcient phenomena and we can write
>>> about them in RDF or english or whatever - but they are not
>>> named by the URI that gave rise to them as
>>> awww:representation in response to an interaction on the Web
>>> - for that name is already used up to name the thing that
>>> they are an awww:representation of.
>>>
>>> Strangely, and mayber preversely, I think that things are
>>> already pretty clear.
>>>
>>>
>>>       
>>>> Xiaoshu
>>>>
>>>>         
>>> Stuart
>>> --
>>> Hewlett-Packard Limited registered Office: Cain Road,  Bracknell, Berks RG12 1HN
>>> Registered No: 690597 England
>>>       
>
> Stuart
> --
> Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
> Registered No: 690597 England
>

Received on Friday, 13 February 2009 16:29:18 UTC