Re: Issue-57

On Fri, Jun 24, 2011 at 3:33 PM, Larry Masinter <masinter@adobe.com> wrote:
> 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.

In what sense can someone believe something, if they don't know what
it means? In fact, how can one even decide whether one wants to
believe something, or test whether it holds (don't know why the scare
quotes), without knowing what it means?

You allergy to the word "meaning" here is very strange. You use the
word at least 50 times in one of your best-known pieces of writing,
RFC 2616. These uses are unproblematic, as far as I can tell. What
about this conversation do you think erodes the colloquial utility of
the word "meaning"?

You're not alone, though. FOL (including RDF) seems to frighten those
who haven't internalized it and makes them lose confidence in even the
most ordinary words. It's odd that other declarative formal notations,
such as HTTP headers, don't have this effect. Unfortunately I don't
know how to dispel fear of logic by writing email messages.

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

I think you're trying to strike down a straw man. Ambiguity applies to
utterances, not interpretations or models, and it reflects a simple
lack of information. There is always more information to be had, so of
course there is always ambiguity to dispel.

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

If Bob says this I haven't a clue what language he's speaking. The
meaning, if any, would depend on what prior understanding exists
between Bob and Alice, and I'm not privy to that.

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

I'm not sure what in this is *not* meaning. To reduce ambiguity you
ask someone what they mean (among a set of alternatives). The question
of model or interpretation is a red herring - these aren't observable
or predictable. What's important is what the sender and receiver agree
on, and what they say and do.

If you want an inclusive framework the thing to look at is
equivalences and implications: if I see abc in notation A, can I
correctly write xyz in notation B? In other words, how do the meanings
of the two notations correspond? FOL is a pretty good way to do this
kind of analysis, but informal methods work too.

Jonathan

> 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, 19 August 2011 16:11:25 UTC