- From: Jonathan Rees <jar@creativecommons.org>
- Date: Mon, 14 Jun 2010 12:41:58 -0400
- To: AWWSW TF <public-awwsw@w3.org>
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 normative. 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 closest: 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* operational: 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. Jonathan
Received on Monday, 14 June 2010 16:42:32 UTC