RE: Issue-57

Well, I wind up finding it useful -- and perhaps even necessary -- to frame the discussion in terms of communication, trust, and belief rather than just in "meaning". 

Rather than talking about whether
     <http://example/z> xhv:license <http://example/l1>.
"holds", talk about two parties (Alice and Bob), where Alice asserts 
   <http://example/z> xhv:license <http://example/l1>.
to Bob, and how that assertion might affect Bob's beliefs.

Bob knows that Alice's interpretation of <http://example/z> is
ambiguous, just as Bob knows that Alice's authority to assert
licenses for any of the interpretations <http://example/z>  may
be in question. 

I was considering ways in which Alice could reduce some
of the ambiguity (by saying more about Alice's interpretation
of <http://example/z> ), but I don't imagine there are any
cases of an _unambiguous_ model.

And if Alice instead asserts

   <http://example/z> license l1

(using unqualified relations and even license identifiers), the
result is that Bob has even more ambiguity to deal with, that
Bob knows less about Alice's belief about the license for
<http://example/z>.

At least for me, thinking along these lines seems to be a way of
creating  a framework that could include RDF and microdata,
putting the two systems in the context of ambiguous 
communication, rather than strictly focusing on "meaning".
Every communication is ambiguous because the receiver is
not certain of the interpretation of the model that the sender
is using, and the technology we provide disambiguates to
one degree or another.

Does that help?

Larry
--
http://larry.masinter.net



-----Original Message-----
From: Jonathan Rees [mailto:jar@creativecommons.org] 
Sent: Friday, June 24, 2011 10:50 AM
To: Larry Masinter
Cc: Xiaoshu Wang; Alan Ruttenberg; Tim Berners-Lee; David Booth; Jeni Tennison; www-tag@w3.org List
Subject: Re: Issue-57

On Fri, Jun 24, 2011 at 1:05 AM, Larry Masinter <masinter@adobe.com> wrote:
> Using a URI to identify a resource has ambiguity in many dimensions, not just use/mention.
>
>>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.
>
> Is the license for z just for R, or does it apply to, say, any transcluded content?
> Does it apply to the R that is returned NOW, or does it apply for all time?
> Does the license apply to the whole site, or just the "home page"?

You are asking an empirical question. Here is how I think metadata of
this sort is currently interpreted in the wild, most of the time.

The first is indefinite and is a cause of concern - there may be some
miscommunication occurring. But I'd say most of the time (not all)
either there is no transcluded content or the impact of any
transcluded content doesn't matter, so the statements are still
useful.

In the second case it is current and future representations. How long
the statement is thought to be true depends on the communication
context; for the most part RDF is ephemeral and the temporal extent of
the statement is similar to the extent of a similar hyperlink.

Usually, in RDF, a URI refers to a page or document or image. Maybe
some people use them to refer to sites, and are understood when they
do, but I'm not aware of examples.

>>My interlocutor wants me to be able to infer that
>>
>>    R xhv:license <http://example/l1>.
>
> I don't know how xhv:license can relate things that aren't given
> by URIs.

The same reason that rights in _Pale Fire_ (the novel) could be
licensed, before there were URIs.

This discussion isn't restricted to RDF, but RDF is referentially
transparent (by specification) as should be any language used in civil
discourse (in my opinion).

Apparently we have a cultural mismatch here regarding how relations
like xhv:license work. I'm not sure what it is.

> But let's imagine that R is a sequence of bytes RB with media type RT,
> where RBE is the base64 encoding of RB.
>
>    data:RT;base64,RBE
>
> is the 'same' representation R.
>
> Does <data:RT;base64,RBE> xhv:license <http://example/l1>  hold?

By your construction the data: URI is another name for R, so this
follows by referential transparency.

> I think that's only one of the interpretations of the original assertion.

Indeed, many interpretations are possible. But I'm talking about two
kinds: interpretations that the httpRange-14 rule advises, and the
interpretations that I see in the wild, where RDF is used to express
metadata on the Web. In both cases the interpretation is as I say, as
far as I know.

> I'm thinking that rather than trying to disambiguate these possible interpretations dynamically (by  restricting the URIs to HTTP URIs and attempting disambiguation by whether the HTTP server returns one status code or another), that the disambiguation should be made explicitly

OK, now you're talking about alternatives to the rule, not what it
means or whether it's observed. Did you read either of the notes I
wrote? They both talk about unambiguous notations that are
alternatives to http: URIs. (I don't give a way to express all of the
things you want to say, but I didn't set out to.)

> <the-content-visible-when-rendering-the-results-of-accessing-at-any-time http://example/z>  xhv:license <http://example/l1>
>
> If I want to explicitly disambiguate that I mean
>  - at any time
>  - including transcluded images
>  - not including any other content
>
> Likely this is an approach that has been tried before, but if so, kindly point out why it was rejected.

It has certainly not been rejected, but it has not been pursued, in my
opinion, because given the httpRange-14 rule, nobody has felt much
need for it. They use URIs to refer to web pages, and they're mostly
happy. Maybe the need exists - one would certainly expect that it does
- but it is not to my knowledge a current pain point for any
constituency. Not that I would necessarily know, but I keep my ears
open for this kind of thing.

I think you're saying the OK is the enemy of the correct. Maybe so,
let's talk about it.

> The use/mention ambiguity is useful. If I invent a cartoon character and want to license the _character_ (and not just the drawing of the character), I might usefully want to apply a license to the "thing described by" a drawing, or leave it ambiguous exactly how close some other drawing has to be before it is the "same" character.

What is licensed and under what terms is usually spelled out in the
license terms document and related statute and case law...

To refer to a page's primary topic we usually use the
foaf:primaryTopic relation or something similar.

You can express anything you want in RDF, you just have to create an
appropriate vocabulary. Refusing to agree with others on what a URI
refers to is perfectly fine, but it means that if you want to
communicate, you have to come up with a way that doesn't rely on the
URI.

If you want to say that you don't agree to let http: URIs refer at
all, that's OK, I'll be sure to remember not to use them that way when
talking to you, and we can talk about new notations to replace linked
data. This is revolution, not reform.

I know I'm coming out as partisan but in the end what I want is just a
standard for certain simple cases of Web metadata. (I thought we had a
Resource Description Framework, and it's turning out that maybe we
don't.) I think it would be unwise to throw away what little we've got
without pretty careful thought, since the cost of deploying something
new would be very high. But maybe in this case revolution will be
easier than reform, I don't know.

Thanks for your comments. I will be interested to know what you think
appropriate next steps would be.

Jonathan

> Larry
> --
> http://larry.masinter.net

>

Received on Friday, 24 June 2011 19:34:26 UTC