Re: New draft of section 5.5

On Mon, Apr 4, 2011 at 9:34 PM, David Booth <david@dbooth.org> wrote:
> Attached is an updated version.  Inline responses . . .
>
> On Mon, 2011-04-04 at 16:37 -0400, Jonathan Rees wrote:
>> "its meaning should be obtained from that definition instead of from
>> the httpRange-14 rule regarding information resources."
>> - I invoke the "IR reference rule" in the document, and it can be hyperlinked.
>>   (Actually the httpRange-14 rule as we know is wrong in all sorts of
>> ways to referring to it directly is very risky.  E.g. we know the
>> purpose isn't to say that the URI refers to *any* information
>> resource, i.e. it has nothing to do with typing; it really means to
>> say - and I think most people have understood it to say - that it
>> refers to a *particular* information resource.)
>
> Yes, I think I agree, but I'm not sure what you are suggesting.  My note
> "[TODO: Say somewhere what the httpRange-14 rule is]" was meant as an
> editorial reminder that we should say more explicitly what inference
> rule we mean, when we refer to the "httpRange-14 rule".  In that draft
> document I have assumed that the consequence of the rule consists of the
> two assertions in graph gh, but we really should say explicitly (e.g.,
> in n3) what rule we're assuming.
>
>>
>> "Because of the 200 status code, Bob applies the httpRange-14 rule and
>> concludes the following:"
>>
>> It doesn't matter how Bob concludes that metadata, but it would be
>> harmful to say that a single HTTP response is adequate to justify it;
>> for the metadata to be useful it has to be true of what someone who
>> reads Bob's metadata will get. I think it is better to be vague since
>> this has nothing to do with this section.
>
> But if we don't provide any justification, then we could just as well
> say that Bob concludes that <http://example/p16> refers to an elephant.

No we couldn't - the scenario would be different then.

> The point is that the 200 status code *justifies* Bob's statements about
> <http://example/p16> as a web-accessible thing.

It's not a question of justification, but of convention. Most people
have adopted the IR reference rule. That is why Bob uses it - because
he wants to be understood.

I believe I've corrected the scenario in a few ways since you made
these comments, so perhaps your objections here are moot. In this
case, Alice and Bob and Carol will all know that some new protocol is
in effect, and the question is just what that protocol needs to be.

>>
>> "web:hasUri"  -- the document already defines the predicate (if it's
>> the one I think you mean) and it's called :accessibleVia.  There is no
>> reason to say that the subject has an information resource type and
>> doing so weakens the document.
>
> Okay, I've changed web:hasUri to :assessibleVia throughout.  I also
> removed class web:IR from the RDF, as it is not needed for the
> inferencing, and in the prose changed it to "web-accessible thing".
>
>>
>> Bob actually concludes that the URI refers to the IR at that URI. It
>> is better to say this in English since in the example he really does
>> conclude this. If written in RDF it will have to be translated for the
>> benefit of readers, and that's redundant.
>
> I think it is important to focus on *observable* facts.  What Bob
> privately believes in his own mind is irrelevant.  The point is that
> graph gh is what gives Bob license to make assertions about
> <http://example/p16> as a web-accessible thing.

I disagree. Sometimes arguments on general principle are easier to
understand than those containing distracting and extraneous detail.
And logical arguments are often not in terms of observables, but
rather in terms of ... logic.

>>
>> I don't see any reason to go into such detail on what Carol wants to
>> do. Most of the detail you've provided is unnecessary and distracting.
>> She really just needs to figure out what was meant by each use of the
>> URI.
>
> The point is to nail down more explicitly what we mean by "what was
> meant by each use of the URI".

This seems perfectly clear to me. What confusion do you think someone
reading this might have?

> If we're going to make progress on this
> if we cannot be hand-waving about what we mean by "meaning".

I'm not hand-waving at all and I resent your describing it so.

> We need to
> be very explicit, and that's what I'm trying to do.  We need to make
> *all* relevant assumptions explicit -- such as Carol's implicit rules ri
> -- and we need to be talking about *observable* facts -- not what is
> hidden in Carol's head.

I don't agree. People are very good at reasoning about what is in
heads, and about correctness of applications and protocols.

>>
>> Carol's problem is *not* caused by combining the graphs
>
> Huh?  But the problem does not exist if those graphs are not combined.
> There is no contradiction if those graphs are not combined.

The question is not consistency, but correctness. There are lots of
ways to be wrong without anyone detecting a contradiction.

If I tell you one day that mercury is the closest planet to the sun,
and then the next that it is liquid at room temperature, you need to
figure out what each occurrence of "mercury" means, even if you've
forgotten the second day what I said to you the first day. It has
nothing whatsoever to do with graph combination. It has to do with
correct interpretation.

>>  - it is caused
>> by Alice and Bob using the same URI in different ways. She would have
>> to figure out what they mean
>
> Please be more explicit about what you mean by "what they mean".  What
> RDF assertions will be made?  What *observable* action will occur?

The scenario has little to do with RDF. The question is what is being
communicated and what knowledge the receiver will have after the
communication. It doesn't matter that the sender and receiver are
automata since they will have their own correctness criteria - with
respect to *real* semantics, not hobbled RDF quasi-semantics - and
will need to be subject to audit from agents who are not automata.

>> even if she didn't do any graph
>> combining, if she processed the two graphs separately. In particular
>> she'd be confused about whether to apply the IR reference rule or not,
>> in either case.
>
> Carol's mental confusion seems irrelevant to me, because it is not
> observable.  If her application produces the wrong output, then that is
> observable, and we should talk about how and why that happens.

Carol writes lots of applications and says lots of things. If she's
confused we may very well hear about it. This does not seem like a
confusing point to me. It is just common sense.

> Can you translate Carol's confusion into her application producing
> incorrect output, so that it is observable?

I probably could but I don't see the point. If the example included
"likes" and the "application" had to make a list of information
resources that were liked - something like that. But the main thing is
that Carol (and the artifacts she's responsible for) mustn't say
things that are not licensed by Alice or Bob, like that there exists
an entity (either a canoe or a version or other IR) that has both the
given title and the given mass.

>>
>> The rest seems at best unnecessary to me; and as you know I find your
>> "application" idea to be wrong and harmful as meaning is not a
>> function of application.
>
> The "application" idea is merely a device to enable us to talk about
> observable facts.  There may be a better way to do that, and if so we
> could switch.  But I don't believe we can make headway on these topics
> if we just make claims about unobservable beliefs that are in people's
> heads.  We need to make the discussion absolutely explicit, concrete and
> observable -- no "then a miracle occurs" steps.

I think we can make headway in exactly this way, and do.  This is how
social processes work - you reason about what other people know. This
is not miraculous or mysterious (any more than any other everyday
human process).

>> Cases in which there is no problem due to
>> some coincidence are uninteresting and don't need to be presented.
>
> Which cases do you mean?

The last three examples in your document

>>
>> I had been focusing on how to construct an RDF satisfying
>> interpretation (i.e. proof of soundness) in this case, but I think
>> this is a secondary problem. The first thing is to figure out how
>> Carol would reconstruct the intent, in the best of circumstances.
>
> What intent?  Can you state the problem in terms of observable output
> that is incorrect?

I think this is silly. The receiver needs to distinguish between
possible states of affairs known by the sender. It is obvious that if
you have a properly functioning communication scenario involving a
language with symbols {a, b} (among others), and then replace all b's
with a's in each message, then there is a potential problem in that
states of affairs that are distinguishable in the richer language
might not be in the less rich language. Maybe there is no problem, but
if there isn't that would have to be proved - you'd have to show that
the replacement is harmless. It doesn't matter whether anything is
observable or not - they could be talking about angels on pinheads,
and the communication problem would be the same. It's a problem of
information, not application behavior.

>> If
>> she can do this then I'm sure there'd be some clever formal
>> construction leading to an interpretation. If there weren't, well,that
>> would make the case against this approach quite a bit stronger, but
>> saying so doesn't help in presenting this option, and the first
>> responsibility here is to give it a fair shake - we're not obligated
>> to analyze it in detail, and doing so might even hurt socially.
>>
>> Remember this document is meant to bring people into conversation
>> about issue 57. By going on and on we'd only scare people away. For
>> this section, the people to be engaged would be Harry and Ed Summers
>> and others who think this way. They are not formalists and already
>> have little patience with careful analysis. They should not be
>> bombarded with details.
>>
>> The presentation has to be as brief as possible - just long enough to
>> enable them to recognize that this is the solution that they're
>> proposing, while allowing us to describe the solution in terms used
>> elsewhere in the document to make comparisons possible.
>
> Yes, I agree that when it comes time to present this, we need to make it
> as succinct as possible.  But I don't think we're anywhere near being
> able to do that yet.  I think *we* first need to come to agreement on
> what the problem is.  Once we have done that in in enough detail to be
> sure we have captured it, we can then try to simplify the presentation.
> But thus far, I keep seeing too much hand waving and claims about things
> that are not observable.

I don't know where I'm being unclear. As far as I can tell I have
described the problem pretty well, and since you and I have been
arguing along these lines for years, I have little confidence that
*we* will ever agree. But if you can point to particular points that
you think are unclear or are open to misinterpretation, that might be
helpful as it may give me a chance to sharpen the prose.

Jonathan

>> As I said I rewrote 5.5 last week. I just now fixed a couple of
>> problems with and have tried to fix up a couple of things that might
>> have confused you.
>
> I'll take a look at that also.  I haven't gone through your re-write
> yet.
>
> thanks,
>
>
> --
> David Booth, Ph.D.
> http://dbooth.org/
>
> Opinions expressed herein are those of the author and do not necessarily
> reflect those of his employer.
>

Received on Saturday, 9 April 2011 23:12:40 UTC