Re: Fwd: Splitting vs. Interpreting

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