- From: Sandro Hawke <sandro@w3.org>
- Date: Fri, 26 Sep 2003 01:05:00 -0400
- To: pat hayes <phayes@ihmc.us>
- Cc: public-sw-meaning@w3.org
> Sorry this all has a stream-of-consciousness air about it and rather > jumps from topic to topic, I nonetheless found it compelling reading, thanks. There were about three points I wanted to comment on now. > 1. Let's stop talking about what the meaning of a URI is, or might > be. I suggest that the question is underdetermined, and cannot be > answered sensibly, since 'meaning' can only be said to apply to > larger pieces of representation than single words or URIs. I take "meaning of a URI in RDF" to be a kind of shorthand, handwaving conglomeration of three things about which I have much clearer notions: 1. The effect on the meaning of an RDF graph which using that URI has in that graph. That is, how differently would the graph's truth value relate to the state of the world if a different URI were used in its place? 2. the denotation of a URI in an interpretation 3. the referrent of a URI, a notion about which I see no consensus, but.... My working hypothesis is that "the referrent" is actually the denotation of the URI in any interpretation which satisfies the "introduction" (essentially: initial public use) of the URI. So "the referrent" is actually a multi-valued term, but if the introduction is sufficiently constraining, we shouldn't notice. So talking about the "meaning of a URI" is a tempting shorthand, and it may be more useful than troublesome. If we agreed that it was a gloss for the above, and could switch to the more precise term when necessary, I think we'd be fine. > BTW, URN's are obviously names. They also obviously do not satisfy > the RFC 2396 prose: they do not, for example, provide access to the > things they name or allow operations to be performed on them. I have been led to believe (although I have yet to see it) that suitably configured software can fetch a representation associated with a URI like URN:OID:0.9.2342.19200300.100.4 about as easily as for http://www.w3.org. Different protocols and directories are used, but it's still just internet infrastructure. I think in the early days of the web, people somehow felt like a domain name was firmly attached to a piece of machinery, so that "www.w3.org" might really BE the "location" of something. Now, I hope, we're more comfortable remembering it's just another string we can run though some distributed algorithms to achieve some effects. > (Wanting to subsume URNs and URLs under a common framework may have > been the source of this truly disastrous confusion, BTW.) I think straightening out the story on URNs and URLs could do us a world of good here. (Quickly re-reading sections 2.1 and 2.2 of RFC 3305...) It seems to me that a URN ought to be a URI which is usable as a name, and a URL ought to be a URI for which I can easily get a representation. By this definition, there would be a lot of overlap. Some URIs that are not URNs? Maybe "file:///x" since that's relative to your own machine -- or maybe that's just an indexical name? (Ewww.) Being a URL with this definition is clearly fuzzy: if I installed the right software, URN:OID:0.9.2342.19200300.100.4 would go from being just a Name (URN) to also being a Locator (URL). > Another idea it suggests is that any agent which puts together > information from a variety of sources and draws conclusions from them > in combination (which could not be inferred from one of them alone) > must be understood to be taking upon itself the responsibility for > its conclusions. The act of combination itself is taking a kind of > risk, after all; and what else can be understood to be responsible > for the conclusions? This is a new idea to me, by the way: that the > performance of valid inferences can itself be considered to be taking > a stance, and the conclusions may be at risk even if the sources are > trusted and the inferences are valid. (You may be correct in > trusting both sources, but they may be relying on different > assumptions. Neither of them may be willing to sanction the > conclusions you are drawing.) I expect you will recant this heresy shortly. :-) There is certainly a risk in believing sources, but how can there be an additional risk in making sound inferences from them? As I usually imagine the semantic web, when it's all polished and shiney and doing what I want, most of the claims are available with explanations, which are usually in one of these forms: 1. It was put into the system like this, by Joe Schmo, and he clicked the box that said "This is really true." 2. This was derived by hyperresolution from [source1], [source2], [source3] with substitutions [x/54, y/"Hello"]. Drew McDermott recently argued, I think, that most useful inference methods are not actually sound, so maybe we'll have 3. This was derived by StatisticalMethod7 from [source1] in which case, yeah, whoever made THAT inference is taking an additional risk. Down the road, I have the choice of either taking him at his word (and silently accepting that risk myself), or asking for justifications for each triple and noticing that he used an unsound inference method along the way. -- sandro
Received on Friday, 26 September 2003 01:04:34 UTC