- From: David Booth <david@dbooth.org>
- Date: Wed, 30 Jan 2013 13:30:58 -0500
- To: Larry Masinter <masinter@adobe.com>
- Cc: Graham Klyne <GK@ninebynine.org>, Pat Hayes <phayes@ihmc.us>, Tim Berners-Lee <timbl@w3.org>, "www-archive@w3.org" <www-archive@w3.org>
Hi Larry, On Wed, 2013-01-30 at 08:01 -0800, Larry Masinter wrote: > > For me, there are several intertwined issues here, in no particular order: > > - context > > - ambiguity > > - vagueness > > - sound inference > > - modalities (? - I mean conflicting or differing interpretations in a common > > discourse) > > > > What we *have* in the present model theoretic approach is sound inference. > > In particular, with RDF, the idea that the RDF merge of two (or more) graphs is > > true under exactly the interpretations that make the original graphs true. I > > think this is a key necessity (but not sufficiency) for combining and remixing > > data on the web through automated processing, and of itself represents an > > important step forwards from what we had before. I'm reluctant to let that go. > > I think you can only keep "sound inference" after you've done some kind of > Trust transformation, where the semantics of responses to requests are > Initially posited to not be available for combining and remixing before they > have been explicitly accepted as trustworthy. > > I see no point in distinguishing between ambiguous assertions and > untrustworthy ones, In some cases I would agree, because they both result in unusable data. But in other cases the consuming application does not care about the ambiguity, and thus the URI is *not* ambiguous to that application. And in still other cases the ambiguity can be eliminated by "splitting" the ambiguous identity of one URI into multiple URIs with smaller identity footprints. But in both of these other cases the net effect is that the ambiguity has been effectively eliminated. So yes, I agree: there is no point in distinguishing ambiguous assertions from untrustworthy assertions, because they both result in unusable data. > and I like having a model where trusting is an explicit part of the > interface. This section of "Making Sense of Ambiguity" on "Determining Resource Identity" proposes a standard process for determining resource identity: http://dbooth.org/2010/ambiguity/paper.html#part3 It explicitly leaves the trust decision up to the RDF consumer (to decide what RDF graph to use). Community recognition of a standard process for determining resource identity still would not mean that an RDF consumer would be *required* to use that process. But it would *enable* RDF producers and consumers to indicate and determine the intended resource identities (to the extent possible) in cases where the parties wish to do so. Thus, such a standard process does not tell anyone what data they should trust, but it does tell them the mechanisms to use, to determine resource identity, once they have decided what data they trust. This seems to me to be a reasonable and useful separation of concerns. -- David Booth, Ph.D. http://dbooth.org/ Aaron's Law, in memory of Web prodigy and open information advocate Aaron Swartz: http://bit.ly/USR4rx Opinions expressed herein are my own and do not necessarily reflect those of my employer.
Received on Wednesday, 30 January 2013 18:31:33 UTC