- From: Jonathan Rees <jar@creativecommons.org>
- Date: Wed, 15 Jun 2011 18:48:10 +0000
- To: Alan Ruttenberg <alanruttenberg@gmail.com>
- Cc: David Booth <david@dbooth.org>, Jeni Tennison <jeni@jenitennison.com>, "www-tag@w3.org List" <www-tag@w3.org>
I don't want to get into another argument - or, in reference to the Monty Python skit, contradiction - with David on these subjects, since in four years of attempting to engage we have yet to find any common ground, and I would not expect to suddenly find it today. However others reading this may be wondering whether, as David asserts, I am making a mistake, or making unnecessary class disjointness assumptions. David like to bring this accusation of unnecessary disjointness assertions into discussions, but it's completely irrelevant here, and I continue to maintain that the "is it an information resource" meme continues to be one of the most stupidly incorrect and harmful bits of the debate. I'll provide just a bit more detail on what I meant about induced contradictions, which was part of my answer to Jeni's email and my defense of Ed Summers's and Richard Cyganiak's approach. Suppose that we use URI U1 to refer to Document D1, and that D1 implies that U1 refers to Person P1. Suppose that we use URI U2 to refer to Document D2, and that D2 implies that U2 refers to Person P2. Suppose we believe D1 and D2 (we "take them at face value"). Suppose that Document D1 is (provably) different from Document D2 - perhaps an author of one is not an author of the other. Suppose that Person P1 is (provably) the same as Person P2 - perhaps they have the same US social security number. This is an inconsistent set of axioms. You could make it consistent by ditching consistent reference (i.e. a URI refers to at most one thing), but I'm not sure anyone's ready to do that. I prefer to re-establish consistency by rejecting the last axiom, P1 = P2. To show consistency I reinterpret the class "Person" so that its members are not persons but rather documents. Then two distinct "Persons" can have the same social security number (interpreted as being the social security numbers of the persons that the documents are about) by virtue of being different documents. I reinterpret that "has social security number" property to mean "is about a person with SSN", and voila, P1 :ssn S and P2 :ssn S do not imply P1 = P2. Other interpretations are possible too; I'm just trying to show a way to interpret consistently, and in fact more than that, that the sender's intent can be decoded by a cooperating receiver, which is the important thing. In any case this is a happy state of affairs, relatively speaking. Agents who only care about metadata need not change their behavior, and agents wanting to use U1 and U2 to refer to the people that the documents are about obtain a very good illusion that they are doing so, because all their properties "coerce" a document to a person as needed, in their model. In fact, there might be a theorem in here that would allow them to safely interpret the URIs as people after scrubbing the metadata axioms out of their knowledge base. And everything is consistent, since Harry Halpin tells me that no one who gets close to scenarios like this one is interested in doing inference (of the P1 = P2 sort), and I trust him. (I am glossing over a detail when I say "about" but it's not important, contact me off list if you detect it.) In essence this is a variant of the unique name assumption - you might call it the 'unique document assumption'. I am not saying that this is to my taste; I'm just saying that it's a consistent way to for the metadata composers and take-it-at-face-value people, who appear to be fighting to the death over the coveted linguistic territory of dereferenceable absolute URIs, to coexist. If accepted by them, then there would be no reason to retract the httpRange-14 resolution, because what Richard and Ed want to do would be perfectly consistent with it. This is what the section of the issue-57 document is *supposed* to say. I hate to make the document longer - it's already at 20 pages - but apparently I'll have to. Jonathan
Received on Wednesday, 15 June 2011 18:48:38 UTC