RE: URIs in data primer draft updated & httpRange-14 background

On Friday, March 08, 2013 4:18 PM, Jonathan A Rees wrote:

> On Fri, Mar 8, 2013 at 6:04 AM, Markus Lanthaler wrote:
>
> The note under example 4 is a bit confusing IMHO. You could argue that if
> the image itself can be retrieved at http://photo.example.com/psd/12345,
> then that URI *is* identifying the image. The JSON would just be a
different
> representation of the same resource.
>
> Jeni assiduously avoids the relationship "representation of"
> because different people in this discussion use it in incompatible
>  ways (often without realizing that they do) and the result is very
>  harmful because people talk past each other and argue over words
>  instead of reality. So please do not reintroduce it!

My intention was not to introduce it but to clarify the note.


> The issue is that you can't come up with any coherent property that
> relates X to some other entity, where it is unknown whether X is
> the JPEG or the JSON, because the two "representations" are not
> alike in what they serialize, in what they describe, in what they
> say about the URI, or in any other way. And if something doesn't
> have properties then it isn't anything.

Not sure I understand you correctly. But let's assume for a seconds that the
JPEG *is* the pixels on the screen. Just because it is possible to conneg
that to HTML doesn't mean that it identifies two different resources. I
could represent the same picture in HTML using a differently colored div for
each pixel e.g. Of course it would be insane but that doesn't matter. It is
the same resource. Maybe this makes it clearer why I find the note so
confusing:

[[[
If the URI http://photo.example.com/psd/12345 supported content negotiation
such that a request with Accept: text/html provided an HTML page but a
request with Accept: image/jpeg returned the image, the URI is being used to
identify two distinct resources...
]]]


Cheers,
Markus


--
Markus Lanthaler
@markuslanthaler




------ Full email below since you forgot to send it to www-tag as well -----


From: jonathan.rees@gmail.com [mailto:jonathan.rees@gmail.com] On Behalf Of
Jonathan A Rees
Sent: Friday, March 08, 2013 4:18 PM
To: Markus Lanthaler
Subject: Re: URIs in data primer draft updated & httpRange-14 background


On Fri, Mar 8, 2013 at 6:04 AM, Markus Lanthaler <markus.lanthaler@gmx.net>
wrote:

The note under example 4 is a bit confusing IMHO. You could argue that if
the image itself can be retrieved at http://photo.example.com/psd/12345,
then that URI *is* identifying the image. The JSON would just be a different
representation of the same resource.

Jeni assiduously avoids the relationship "representation of" because
different people in this discussion use it in incompatible ways (often
without realizing that they do) and the result is very harmful because
people talk past each other and argue over words instead of reality. So
please do not reintroduce it! I think the whole point of the memo is that we
should have good property documentation so that all this voodoo-language
about what "resource" a URI "identifies" or whether a representation
"represents" any particular thing becomes moot. These terminology arguments
raged unproductively for over a decade and it is best to set them aside and
try to achieve jargon-free transparency instead. And the proposed way
forward is to agree that when we document a construct (property, in the case
of JSON or RDF) that can involve a hashless URI, we will say in what
particular way the construct's meaning hinges on web behavior at the URI (in
particular a representation retrieved using the URI).

That note is the only place in the document that talks about what URIs
"identify" and as you suggest is a potential problem in the absence of a
story about how retrieved representations relate to what a URI identifies.
However I think the point is still valid and can be made in an
identification-free way. The issue is that you can't come up with any
coherent property that relates X to some other entity, where it is unknown
whether X is the JPEG or the JSON, because the two "representations" are not
alike in what they serialize, in what they describe, in what they say about
the URI, or in any other way. And if something doesn't have properties then
it isn't anything.

Jonathan

Received on Sunday, 10 March 2013 18:38:29 UTC