Re: Naming things with hashes (not #, but e.g. md5)

On Wed, Apr 11, 2012 at 6:50 AM, Larry Masinter <masinter@adobe.com> wrote:
> You're not understanding me, and I'm getting tired of trying to explain.

I appreciate your making one more attempt to explain, because with
each iteration I come closer to localizing the source of the
disagreement.

I don't think I'm doing any of the things you accuse me of, such as
decontextualizing.

Under the assumption of mutual respect we would do well to try to find
the nut of the disagreement.  Unfortunately this activity is not well
suited to long email messages.

(For example, you say "I think that's an impoverished model of
communication" which is a misunderstanding of what I said. I was not
giving a model of communication, I was making a statement of fact,
about what *I* do. I said:

'If I ask what an occurrence (in some context) of a name "means", ...'

To be more explicit what I meant was:

'If I, Jonathan Rees, ask myself what an occurrence (in some context)
of a name "means", ...'

I was not talking about me asking someone else - that would have been
about communication. I will admit that I am not always a clear
communicator. But I will not admit, so far at least, to making
mistakes in the present discussion, as you say I do.

But that's an aside.)

I think we can localize the disagreement to different accounts of
a@href. This has nothing at all to do with RDF. Can we agree on this
(that we have different accounts of a@href) first as a matter of fact?
Here is my account (quote):

'a@href, where they intend for me to
get to content they would be happy for me to get to in that situation.
If the wrong content is served that's certainly not what they intend.'

Here is your account (quote):

'If M is HTML and U appears in a@href, the "meaning" of U in that
context is pretty widely understood as establishing some expected
behavior in B's software when B clicks on the link'

These look pretty different.

These can both be true if intent != meaning. But in English these
words are often used interchangeably, so it will be very easy for us
to get confused about this.

The paradox of the web is, why would anyone use an http: URI, under
the understanding you articulate, when it doesn't express (mean) what
they intend? Let's say they intend for the receiver to go to some
particular document, as in a scholarly reference. They don't intend
the particular network behavior that you say is "meant" because that
behavior might lead to the wrong document - http: is not trustworthy
from the author's point of view. So why do they write an http: URI,
when they are perfectly aware of the risks? Because they don't have
anything else to write that will work in a browser. There is no
standard for addressing content that works reliably in a browser
(yet). They *must* gamble and write something that doesn't mean
exactly what they intend, and just hope that either it works, or that
the receiver will be able to detect failure and perhaps remedy the
problem somehow. They have no choice.

(If they are careful obviously they will surround the a@href with
natural language prose giving properties of the intended document that
can be verified. They can give very weak information, such as
reproducing small bits of content such as title, or strong
information, such as an md5. But the fact remains that a@href with
http: by itself is *always* a substantial leap of faith.)

*Knowing* that others do not have this choice, when we try to browse
old documents, we take special measures when we click on links. Our
top level goal (as people) is not to follow HTTP and a@href correctly
per spec; our top level goal is much more likely to be to recover the
author's intent. We are cautious, knowing we may get the wrong content
due to changes in domain ownership and so on. Any time we believe that
the document we get via HTTP is the document intended by the author,
we are taking a risk. This is the dual risk of the risk that the
author took when they wrote the a@href in the first place.

When I, the receiver/reader, throw the HTTP spec and DNS away and go
to the wayback machine or other archives instead, and succeed in
getting the document that the author intended, then communication has
been successful. When there is agreement between sender and receiver
on the processing of a message then, in my theory, the message "means"
successfully (that's how the theory defines the meaning of a message,
as agreement between sender and receiver). Thus, the URI did not
"mean", to these two parties at least, to use HTTP and DNS and so on -
the meaning ended up being clear, but the mechanism by which it was
interpreted (interpretation != meaning) was quite convoluted and
didn't follow the specs. It was more like an archeological
investigation.

I didn't intend to go on this long, so I will pause here for reaction.
I am not taking a position, I am just trying to do some
analysis/synthesis stuff with you, because I disagree that we
disagree. We are both boneheaded but I don't think either of us is
making mistakes in analysis; it's just a communication failure.

Best
Jonathan

Received on Wednesday, 11 April 2012 13:01:42 UTC