

binding a URI to a thing

From: Jonathan Rees <jar@creativecommons.org>
Date: Mon, 14 Jun 2010 12:41:58 -0400
Message-ID: <AANLkTin9KT2EdCx8CQIjZdTefDjnnyuM8stWJWQW8LKK@mail.gmail.com>
Here is a very long answer to David's question of why don't I understand
"binding a URI to a thing".

Correct me if I'm wrong but I think what you're trying to do is to
define a particular way to connect URIs to "things" that is governed
"normatively" by documents ("URI declarations" or maybe "URI
declaration core assertion documents") in the same way that, say,
media type names
or HTTP header names are controlled normatively by their registrations
with the IETF.  I
can see how you would want to get to this point - it would be the
ultimate in democratic distributed extensibility, allowing anyone to write
a spec and expect others to either accept it or reject it - but I think there
are a number of obstacles to overcome before the idea can even begin
to make sense.

Let me call the set of conventions you're trying to establish "UDMP"
for "URI declaration meta-protocol".

1. In order for UDMP and the URI declarations it deputizes to be
considered normative, there has to be some kind of signal that says
you buy into the idea, and you've provided no such signal. That is,
right now I can use a URI however I like, and I can deny that I
treat or am obligated to treat the UDMP-specified "core assertions" as
To get UDMP to a point where it's as binding on anyone as, say, the
HTTP protocol or XML specification (and that's not very binding!),
you need to use a political process such as the W3 Rec
track. And that means lots of review and lots of politics. The way you
talk about
UDMP, it sounds like a done deal.  That just isn't true.

2. Engineering specifications are normative in some specific context -
they do not apply to everything, but to particular classes of
engineered artifacts such as HTTP servers or robot arms as they
perform particular tasks.  To make it possible to consider UDMP
normative you have to say to what kind of artifact it applies.  One
might have an HTTP-compliant server or client; what kinds of things
might be UDMP-compliant -- SPARQL endpoints maybe?

3. You can't hold someone to a statement of the form "a is bound to b"
under UDMP until you specify how one would test
adherence to such a statement.  Like legal
contracts, engineering specs only work to the extent they are
operationally falsifiable: any party to the agreement has to be
able to check, by observation, to see whether the protocol is
being followed. But there is no way to test whether an agent
"takes statements as true by definition".

4. As I said I don't understand your use of "binding" (or "interpret")
- you are not
providing any way to check whether "a is bound to b" is true, nor are
you telling me what consequences such a statement is supposed to have,
or any way to make use of it.  If you are trying to use the word
"binding" in a way that refers to some traditional use in science and
engineering, as opposed to making up a new sense, tell me what comes

4a. In empirical linguistics, the binding of a phrase (such as a
pronoun or proper name) to another noun phrase is a hypothesis about
how a population of speakers behaves.

4b. In logic, lambda calculus, and programming language semantics, one
speaks of binding a name (variable, etc.) either to another phrase (as
in linguistics) or to some member of some specified semantic domain
(in denotational or model-based semantics). ("Thing" does not qualify as
a semantic domain, as you have not specified it constructively.)

4c. If by "binding" you are referring to "interpretation" (or
"satisfying interpretation") in the
model-theoretic sense, I think this is a misreading of the nature and
purpose of model theory.  Usually in model theory you're quantifying
over interpretations, either in consistency proofs (existence of *any*
satisfying interpretation) or in studying entailment (properties that
hold of *all* satisfying interpretations).  It is indeed permitted in
mathematical tradition to interpret terms such as x in f(x) however you
like, but interpreting x as a dog is done either as a trick to
emphasize just how
arbitrary the grounding is,
or it's done as part of a testable theory involving physical
observation.  Ultimately you have to either do logic for fun, or
ground your interpretations empirically, or just not worry about it
and let interpretation be a completely private or application-specific deal.

An assertion <http://example.com/whitehouse> rdfs:comment "The White
House" could be quite loosely described as binding a URI to the white
house, in the way that the sentence "The dog had a flea." binds "it"
to "the dog" (or the dog? which one?) so that an immediately following
"It had three legs." is clearly a statement about the dog, not the
flea.  The effect of saying that the RDF statement (graph,
declaration, whatever) binds the URI to the White House, even if made
operational (as the similar linguistic statement is), would be just
shuffling words around and I think would get us all confused.  Give me
an algorithm, not muddle of this sort.

5. Let me try to imagine ways in which your theory could be *made*

5a. By translation to natural language.  UDMP would specify an
algorithm for converting an RDF graph into natural language text, and
assuming agreement to UDMP you try to hold the other party (the one
who deployed some artifact that has transmitted the URI) to the NL
version of the graph that is the URI declaration.

In order for this to work, you and the other party have to agree on
all the inputs to the algorithm - that is, how all the URIs resolve,
the ones involved in UDMP itself together with all the ones
transitively for UDMP on URIs mentioned transitivey.  For example, if
the algorithm depends on doing GET to get wa-representations from some
URIs, then the two parties might get different wa-representations and
may not be able to agree about what agreement they've entered into.
And then if one gets a 404 and the other doesn't...  No sane person
would enter into such a meta-agreement without a very clear idea of
what they're being held to, and we don't have any good explanation (yet) of
how that can come about.

Of course this is why I've been focusing on understanding URIs for
documents as a first step - but until we have a protocol for
communicating promises of HTTP behavior stability, or some other way
to refer to documents with agreed on properties, it seems premature to
invest much in designing a protocol like UDMP that depends so deeply
on it.

5b. You might try to make UDMP normative for a SPARQL endpoint.  Maybe
an endpoint conforms to UDMP if whenever a URI is seen in a SPARQL
response, the endpoint can be "held to" the UDMP URI declaration for
that URI.  Then we define "held to" in some way, e.g. an endpoint can
be held to a graph (e.g. the URI declaration) might mean that the
endpoint never appears (on the basis of SPARQL responses) to "believe"
something in contradiction to the graph that is the combination of the
endpoint's graph and the declaration.  (or maybe all declarations it
has ever seen, or something.)

"Held to" would then assume some particular logic, so that both
parties to the UDMP agreement agree, ahead of time, to what the
endpoint can be held to.  ABLP logic is a good exampe of a protocol
that does exactly this, e.g. it builds in modus ponens so that if A
says 'p implies q' and A says 'p', then A can be held to 'q' even
though it didn't say it explicitly. But what logic would you pick - RDF,
RDFS, Common Logic, or one of the many OWL dialects?

The protocol will have to explain the intended lifetime of the
agreement, or else there will be disputes over that.

6. Even if you could do it, committing to a single interpretation is a
bad idea.  It is of great value to be able to argue about the
interpretation of words and to change one's mind.  While naively it
might seem like ambiguity and judgment are annoyances, and of course
they are in many instances, I think multiple interpretations,
provisional interpretation, and reinterpretation are the essence of
much of the human endeavor, especially in science and law.  This is
the way progress is made: you explore consequences, change your mind,
and change your assumptions.

Remember that the point of using a URI is for communication between
a sender and a receiver, and it may be that neither one is the URI owner.
Any documentation provided by the owner is there only as a coordination
point, like a dictionary. If the sender uses the URI "wrong" the
receiver will want to
figure out what the sender really meant, even if that is at variance with
something the URI owner said. This is the difference between prescriptive
grammars and descriptive ones - and the prescriptivists lose most of
the time, because they have no stake and no power.

7. Other theories of "URI meaning" are actually in use and we can
either make use of them or parameterize the AWWSW project over them -
thus there is no particular reason to commit to UDMP or any other
protocol, even if we did agree to it and fleshed out the details.  For
instance, Harry has a view that's completely unlike yours, but which
is internally consistent and sensible.  Pat has yet another view,
TimBL another.  If UDMP were further developed, both technically and
socially, and had a following, I would pay it more attention, but for
now I have to continue saying it doesn't make sense.

Received on Monday, 14 June 2010 16:42:32 UTC
