- From: David Booth <david@dbooth.org>
- Date: Thu, 18 Jun 2009 15:41:06 -0400
- To: Alan Ruttenberg <alanruttenberg@gmail.com>
- Cc: "Sean B. Palmer" <sean@miscoranda.com>, www-tag <www-tag@w3.org>
On Thu, 2009-06-18 at 08:53 -0400, Alan Ruttenberg wrote: > From: Alan Ruttenberg <alanruttenberg@gmail.com> > (apologies for the resend, Sean - missed the cc's in the first response) > > On Tue, Jun 16, 2009 at 3:23 PM, Sean B. Palmer <sean@miscoranda.com> wrote: > > > > You write about ambiguous and specific references here: > > > > http://dbooth.org/2007/splitting/ > > > > When I worked on EARL in 2002, we had to solve httpRange-14, and we > > did it in a practical way which your splitting document reminds me of. > > > > We might want to evaluate a tool of some kind in EARL, say the W3C > > Validator. But then we didn't know whether validator.w3.org was the > > tool itself or a page about the tool. That's httpRange-14 in a > > nutshell, before it was “solved” with the 303 hack. > > > > So what we did was this: > > > > <http://validator.w3.org/> earl:tool _:Validator . > > > > The clever bit is that the earl:tool property says: if the subject is > > a Document (i.e. an IR), then the object is the Tool described by that > > document; whereas if the subject is a Tool, then the object is simply > > the same thing as the subject. > > This isn't quite the same idea as splitting (which is more > problematic). Here the ambiguity is maintained due to not completely > constraining the interpretation of http://validator.w3.org/. > Essentially, you are asserting, as a consequence of the use of > earl:tool, that http://validator.w3.org/ is of type unionOf(tool > document). However, assuming that tool and document are disjoint, you > can't use http://validator.w3.org/ both in one place which forces it > to be of type document (e.g as the target of foaf:page), and another > which forces it to be a tool (e.g. http://validator.w3.org/ > :runUnderOS :linux). Doing so would lead to a logical consistency. > Dave's splitting proposal, OTOH, lands up recapitulating the > class/instance distinction with another mechanism, one which doesn't > offer the same support for reasoning that that the existing SW stack > offers. > What I like about your solution is that you at least admit that > documents and services are different sorts of things, instead of using > a term inconsistently. The problem is that inevitably different applications will *need* to use the same term in inconsistent ways -- not because they ignore the definition of the term, but because they make finer, but inconsistent distinctions than the original definition included. For example, suppose the owner of app0 mints a URI http://example#apple with a particular URI definition that is given by a set of RDF assertions involving that URI. In RDF semantics, an "interpretation" maps a URI to a resource, and the rules of RDF semantics constrain the set of interpretations that are possible for a given graph, thus constraining the set of resources to which that URI may map. For brevity I'll call this set of resources the set of possible *interpretations* for the URI. So initially, considering only the graph corresponding to those assertions provided by the definition of http://example#apple, by the RDF semantics the set of possible interpretations for http://example#apple corresponding to that graph will be some set, as illustrated in Figure 2 of http://dbooth.org/2009/denotation/ Let's call this set R0. Now, when app1 adds its own application-specific assertions to the mix (in combination with the assertions for the definition of http://example#apple) the set of possible interpretations for http://example#apple becomes a *subset* of R0. Let's call this subset R1. Fine so far. But now app2 comes along independently of app1, with its own application-specific assertions. Once again, the combination of app2's assertions and the assertions for the definition of http://example#apple produce a new set of possible interpretations for http://example#apple, R2, which is again a subset of R0. Again, so far so good. But what happens when a third application app3 later tries to combine the assertions used by app1 with the assertions used by app2? If the intersection of R1 and R2 is not empty, then all is fine: there are possible interpretations for http://example#apple. But if the intersection is empty we have a problem: http://example#apple has been used inconsistently between app1 and app2. Both usages were consistent with the URI's definition in isolation, but the combination is inconsistent. This is exactly the problem of ambiguity that we've been discussing. The definition of http://example#apple was ambiguous -- it admitted multiple interpretations. And as we know, it is generally not possible to make a definition admit only one interpretation. This ambiguity was not a problem to app0, and it was not a problem to app1 or app2 in isolation, but it was a problem to app3 that needed to distinguish between the notion of http://example#apple that app1 used and the notion that app2 used. > If *everyone* used http://validator.w3.org/ in > this way, it could work. > But if everyone is to use the same scheme, it would seem better to me > to define a new type that made directly clear the nature of > http://validator.w3.org/ as being a sort of service which can do two > different things a) respond with a report about conformance to RDF > syntax of a supplied document and b) respond with a page that > documents how (a) works. Do you mean that http://validator.w3.org/ would denote a resource that has attributes both of being a Document and of being a Tool? I.e., it is both a Document and a Tool? If so, that sounds reasonable to me. > Then have two *unambiguous* properties a) > earl:tool that relates http://validator.w3.org/ to an entity whose > type is tool, and b) foaf:page that relates to a document. It would be > helpful to document, as well, that the tool (b) generates a new > instance of document, each time it is "run". > -Alan -- David Booth, Ph.D. Cleveland Clinic (contractor) Opinions expressed herein are those of the author and do not necessarily reflect those of Cleveland Clinic.
Received on Thursday, 18 June 2009 19:41:39 UTC