W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > November 2007

Re: Issue with top-down and bottom-up semantics

From: Bob MacGregor <bob.macgregor@gmail.com>
Date: Wed, 31 Oct 2007 17:10:17 -0700
Message-ID: <a0d0f8f70710311710n49fec2efyb72d03c3c2bb96db@mail.gmail.com>
To: "Pat Hayes" <phayes@ihmc.us>
Cc: "Francis McCabe" <frankmccabe@mac.com>, public-rdf-dawg-comments@w3.org
On 10/31/07, Pat Hayes <phayes@ihmc.us> wrote:
> >
> >Your assumption that the Semantic Web is open world is unwarranted, i.e.
> does
> >not stand up empirically.   Assuming that information is locally
> >complete is highly
> >useful more often than not.  The open world assumption does seem to
> >be widely accepted
> >among academic types, and makes for a nice sound bite, but we find in our
> >own applications that negation-as-failure is highly useful, while
> >the open world
> >assumption most of the time makes the logic less useful.  Although
> >its adoption is not
> >mandatory in our implementation, we assume UNA and CWA in all of the
> >applications that I have seen.
> >We also employ a variant of OWL that makes the same assumptions, and is
> >therefore much more useful than standard OWL.
> We all have been arguing about this for years, and I now think that
> everyone is right. The SWeb is globally open-world, no doubt, but it
> is chock full of locally-closed-world information sources, and often
> these are the ones that get used for practical work. We need both
> kinds of reasoning, and a methodology (which we don't have yet) for
> using them together without getting confused. The main problem, seems
> to me, is how to say in what respect (ie concerning what 'kind' of
> information or query) a given knowledge source is closed. I don't
> know how to talk about kinds of information. (Anyone have any ideas?)

Your description is on the mark.  It is often difficult to make global
closure assumptions that are both correct and useful.  Instead, our
closure assumptions are typically associated with the choice of operator
in a query (e.g., choosing between NOT and UNSAID).  This doesn't
make much of a contribution from an ontological standpoint, but it
does enable us to get much practical work done.  And it doesn't
interfere with anyone who prefers open-world semantics.

As for UNA, I bet you aren't really using strict UNA, but a weaker
> form which might be called UNA-light: assume different names denote
> differently unless there a very good reason to conclude otherwise:
> and when that happens, fix it by substituting one name for the other
> so as to make UNA more likely next time. Something like that, am I
> right? Because others use that, and that seems to be a very good
> strategy to use even on the normal Web. Given two random URIs, the
> chances of them co-referring are vanishingly small; nevertheless, it
> does happen sometimes, and the costs of getting that wrong can be
> very high.

Our preferred "fix" for UNA is to add an owl:sameAs assertion between
two otherwise distinct URIs.  That makes it a non-monotonic semantics.
So yes, its not "strict".  I figure that the term "assumption" within the
acronym implies that strictness is not assumed.  We don't do exhaustive
consistency checking to infer local deviations from UNA, so in that sense it
is "lite".
However, we don't typically make much use of constraints or IFFs; instead,
most of our logic is Horn-like, which means that there is little difference
a "lite" semantics and a full one (if I'm interpreting your term "lite"

> --
> ---------------------------------------------------------------------
> IHMC            (850)434 8903 or (650)494 3973   home
> 40 South Alcaniz St.    (850)202 4416   office
> Pensacola                       (850)202 4440   fax
> FL 32502                        (850)291 0667    cell
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Robert MacGregor
Chief Scientist
Siderean Software, Inc.
Mobile: 310-469-2810
Received on Thursday, 1 November 2007 00:10:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:09 UTC