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

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.

>  Then, my point is: with regard to "the:png" and "the:ttl",
> "pgn" and "ttl" are representations of different things.

awww:representations, 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?

[BTW: I think URI are used links in such away that <uri> pol:represents <pol:thing>]

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

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

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

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.

> >> 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 15:19:17 UTC