Re: New draft of section 5.5

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

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

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

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

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

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

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

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

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

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

> 
> 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 Tuesday, 5 April 2011 01:34:52 UTC