- From: David Booth <david@dbooth.org>
- Date: Fri, 30 Mar 2012 16:09:48 -0400
- To: Jonathan A Rees <rees@mumble.net>
- Cc: Tore Eriksson <tore.eriksson@gmail.com>, Tim Berners-Lee <timbl@w3.org>, トーレ エリクソン <tore.eriksson@po.rd.taisho.co.jp>, www-tag@w3.org
On Tue, 2012-03-27 at 21:02 -0400, Jonathan A Rees wrote: [ . . . ] > The point here is that it's all about meaning, not truth. +1 that it's not about truth. -1 that it's about meaning. It is not. That is a huge, pervasive misconception that we need to get past. It is all about *definitions* and *usefulness*. Whether/how those definitions are interpreted as meaning or truth is completely irrelevant to the architecture. As a vague overarching goal, it is fine to say that we're after meaning, and even truth! But as soon as we set out to have serious engineering discussions on semantic web architecture, such language is harmfully misleading: - The mere term "the meaning" wrongly suggests that there *is* (or can be) a single meaning for a URI i.e., that it is possible to have an architecture in which each URI has a unique referent. That *is* possible within a particular client application -- or in RDF semantics parlance, a particular semantic "interpretation". But it is impossible at the global level that the architectural must deal with. - It leads to rat holes such as whether something really is or is not an "information resource", or (even if that term is avoided altogether) exactly what properties should be assumed if something has a "representation". - It confuses the engineering problem and leads to hopelessly convoluted definitions, like this one, from the "baseline" document: [[ A representation is hereby defined to _carry_ URI documentation for a given URI if it contains the URI documentation (with or without other information), the syntax and semantics of the documentation is as determined by the media type of the representation, and the documentation occurs unqualified. It is difficult to define "unqualified" precisely for all media types, but we generally mean by this that the documentation is given "sincerely", not quoted, conditionally, or modally. That is, if D is URI documentation and a carrier says in effect that D is not or might not be true, then D, although it occurs in the carrier, is not considered to be carried by it. (E.g. documentation that occurs in an XML literal inside of an application/rdf+xml representation is not unqualified, and therefore not "carried" by it under the present definition.) A "URI documentation carrier" for a URI is a representation that carries URI documentation that bears on the meaning of that URI. Applying the adjective "nominal" is a technicality that signifies that being a URI documentation carrier for the URI is expected according to this specification, but that it might not actually be one (for example, the representation might be empty, or it might contain information, but not information that helps to document the URI, perhaps as the result of a mistake). ]] I recognize the desire to have RDF statements on the web *mean* something in the real world, and clients are free to interpret them that way if they *choose* to do so. Furthermore, it is important that the architecture support clients' ability to interpret them that way *if* they choose. That is critical. But from an architectural perspective, it is the wrong way of looking at the problem, as it just clutters up the engineering and leads to pointless debates and confusion. (However, it *does* have value from an academic perspective, as it fills in the logical formalisms that explain how this all works in the case where a client chooses to believe a set of RDF statements from the web. And eventually such analysis will lead to the same architectural conclusions, but that's a very long and torturous route around the lake to get to the beach next door.) From an architectural perspective, "meaning" and "truth" are the *wrong* goals -- the *wrong* metrics for judging the semantic web architecture. The important metric is *usefulness* to applications. And that is inherently *relative* to each application. The goal overall is to maximize total usefulness to the community. The basic requirements behind issue-57 and the httpRange-14 rework are: 1. There must be a standard, algorithmic way for a client, given a target URI, to find the URI owner's implicit or explicit *definition* for that URI. 2. The URI owner must be able to provide an arbitrarily detailed definition (though not necessarily for a URI of every possible syntactic form). 3. In the case where a URI owner has served a page with no explicit URI definition, the algorithm must specify an implicit definition (though possibly empty). Of course, there are many other motherhood-and-apple-pie requirements as well, such as graceful degradation in the face of inconsistencies, ease of use, general utility, and harmony with the rest of web architecture. And in deciding what the implicit definition should be, a key consideration is to weigh the cost/benefit trade-offs between URI owners and clients, to figure out what would best benefit the community overall. Some of the proposals we've seen essentially advocate an empty implicit definition; others advocate implicit definitions with varing levels of content. Bottom line: We'll get a lot farther a lot faster if we forget about trying to define either meaning or truth, and simply focus on definitions and usefulness. -- David Booth, Ph.D. http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of his employer.
Received on Friday, 30 March 2012 20:10:15 UTC