W3C home > Mailing lists > Public > www-tag@w3.org > June 2011

Re: Issue-57

From: Xiaoshu Wang <xiao@renci.org>
Date: Fri, 24 Jun 2011 03:36:32 +0000
To: Jonathan Rees <jar@creativecommons.org>
CC: Alan Ruttenberg <alanruttenberg@gmail.com>, Tim Berners-Lee <timbl@w3.org>, David Booth <david@dbooth.org>, Jeni Tennison <jeni@jenitennison.com>, "www-tag@w3.org List" <www-tag@w3.org>
Message-ID: <CA297469.1131A%xiao@renci.org>


On 6/23/11 10:16 PM, "Jonathan Rees" <jar@creativecommons.org> wrote:

>On Thu, Jun 23, 2011 at 3:08 PM, Xiaoshu Wang <xiao@renci.org> wrote:
>>
>> The original purpose of httpRange-14, I guess, is to avoid ambiguity.
>>But
>> ambiguity can only be cleared with more ontological assertions.
>> httpRange-14 has raised more confusion/debate. Except transferring
>> ambiguity to a different term, what problem it has solved?
>
>I can see you're getting hung up on unimportant points, so let me try
>again.
>
>Let's make sure we're talking about the actual problem to be solved,
>since it's easy to lose track in all the irrelevant ontological
>hand-wringing. This is not a philosophical or ontological problem;
>it's pure engineering.
>
>Suppose the following holds:
>
>    <http://example/z> xhv:license <http://example/l1>.
>
>Suppose that I do a GET of 'http://example/z' and retrieve a
>"representation" R.
>
>My interlocutor wants me to be able to infer that
>
>    R xhv:license <http://example/l1>.

First, let me make this clear. I have never denied the problem you
described here is not a problem. My argument has always been httpRange-14
is a wrong solution to the problem.

This is a significant jump. You are suggesting that an HTTP-URI references
to a "Representation". I believe this is not what the current AWWW says. I
believe this is, perhaps intensionally avoided, in the AWWW.

In your case, HTTP-URI will be just like a file-URI. But HTTP protocol is
totally different. When you take content negotiation into play, which
version of R that you are suggesting? If <http://example/z> can get back a
JPEG image, which is licensed by <http://example/l1>, will the same
license apply to an RDF representation of it?

Thus, you will need more than specifying 200 to do that.

>
>so that my remix tool knows what license terms apply when using the bits
>in R.
>
>Anyone who likes web architecture (Tim's and the 2005 TAG's, not Roy's
>or yours) would say that this inference is exactly what the
>httpRange-14 resolution is meant for. If web architecture can be
>assumed, then the inference is valid.
>
>Anyone who doesn't, and rejects the resolution, says the inference is
>not valid, so this won't work. If you cast about for an interpretation
>of 'http://example/z' there might be more than one - the intended one
>is an option, but if R *describes* some entity E satisfying
>
>    E xhv:license <http://example/l2>.
>
>where the license terms in l2 are quite different from those in l1,
>then absent httpRange-14 E would also be a plausible interpretation of
>'http://example/z' (consider the relation of _Bleak House_ the novel
>to the page at 'http://en.wikipedia.org/wiki/Bleak_House' - these are
>licensed quite differently). And there might be others.

I don't know why this is a problem?

R xhv:license <http://example/l1>.

E xhv:license <http://example/l2>.

So? I don't understand.

What if 'http://en.wikipedia.org/wiki/Bleak_House' 200 returns a web page
containing the following phrase:

This URI -- 'http://en.wikipedia.org/wiki/Bleak_House' -- refers to the
book "Bleak House" and it is licensed under <http://example/l1>.
The web page, I.e., what you retrieved from the URI
"'http://en.wikipedia.org/wiki/Bleak_House' is licensed under
<http://example/l2>.

In the case when someone tell you:
'http://en.wikipedia.org/wiki/Bleak_House' license <http://example/l1>


In the case of a license violation, I guess TAG would side with the
offender and put the web developer in jail. But I believe most judge, if
not all, would side with the developer.
    


>
>That's the ambiguity that is being addressed - what is related by
>xhv:license to l1, the representations coming from GET of
>'http://example/z', or something else (E). It has nothing to do with
>ontology.
>
>So if you (or the agent you're talking to) don't agree to the
>architecture, the statement about <http://example/z> is not an
>effective way to communicate information about the representations R,
>and you have to coordinate some other way to say it. If you start
>looking for a different way to express this meaning, then I have
>proven my point that the architecture is useful; you are just on the
>road to showing it's unnecessary or undesirable, which is a different
>question.
>
>And if you are saying that the resolution is impractical and will
>never get adequate uptake, then I have also proved my point, since
>that would say that, if counterfactually agreed on, it would have some
>value to someone.
>
>Of course the httpRange-14 resolution as stated doesn't allow the
>desired inference, since the rule doesn't tell you *which* information
>resource is "identified", but that is a bug that I think we all now
>recognize. What was really meant was that the URI "identifies" a
>*particular* resource, namely the one whose associated
>"representations" are retrieved (i.e. are 2xx responses) from that URI
>- and I think this is pretty obvious, so obvious that no one thought
>to say it at the time.
>
>In order to do the inference above there is absolutely no need to do
>ontology around "information resources". It really doesn't matter what
>they are, and we may not even need the term at all - I didn't need it
>in the above exposition. It's unfortunate that the foolish
>"information resource" meme has tripped up so many of us (I know, I
>was stuck on it too for a long time).

Can httpRange-14 solves the above problems, I.e., multiple representations
and information authority? I doubt it. It is too limited an approach
trying to solve a problem of a much larger scope and of entirely an
different nature.

Xiaoshu 
Received on Friday, 24 June 2011 03:37:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:36 GMT