[Top] [All Lists]

Re: [ontolog-forum] Constructs, primitives, terms

To: ontolog-forum@xxxxxxxxxxxxxxxx
From: "John F. Sowa" <sowa@xxxxxxxxxxx>
Date: Tue, 13 Mar 2012 11:45:37 -0500
Message-id: <4F5F79B1.3020206@xxxxxxxxxxx>
Dear Matthew, Pat, Chris, David F, and Doug F,    (01)

> And if ontologies only guarantee something partial, what is it that
> they DO guarantee?    (02)

That is the critical question.  Before we can discuss it meaningfully,
we have to look at some systems that interoperate successfully and
others that don't.  Then we can ask how and why.    (03)

> Logic does not have all the answers here.    (04)

Logic is a tool.  You can't solve any problem by just looking at
the tools.  You also have study the actual problems themselves.    (05)

> The problem is that any necessary condition added to a class creates a
> subclass, and both companies will know that they cannot rely on accurate
> communication unless the subclass condition is communicated to the other
> communicating system. Each system receiving information can only rely on it
> being consistent with the logical specifications communicated by the sending
> system.    (06)

That is true.  But the problem is more complicated:    (07)

  1. Even if every term could be defined by necessary and sufficient
     conditions, you could still have specialized uses in different
     contexts.  But most practical applications have many terms that
     cannot be defined by necessary and sufficient conditions --
     for example:  employee, customer, business, product, cost,
     patient, disease, therapy, life, death...    (08)

  2. For any application that uses such terms, it's unlikely that the
     definitions in a general ontology G permit exactly one model. But
     an upper ontology is *intended* to support multiple models.    (09)

  3. When you take a term defined in G, and use it in a context that
     adds more information (e.g., almost any practical application),
     any or all of the shared terms might be used in a more specialized
     sense -- for example, a subclass or subtype.    (010)

  4. If you have to add qualifiers to every term that might be used
     in any specialized sense in any application, that defeats the
     hope that shared vocabularies defined by shared ontologies
     with unique identifiers can, by themselves, solve the problems.    (011)

Now, let's consider a successful example of interoperability among
thousands of businesses that use a shared vocabulary with enough
shared structure to support applications:  the Amazon.com database.    (012)

Amazon sells a huge number of products, and they could never define
all of them precisely.  So they don't even try.  They do have some
loosely defined product categories (books, electronics, etc.) but they
let each supplier choose the category labels for their own products.    (013)

The suppliers can define their products in any way they please.  But
the only product description that Amazon requires is a character string
that the Amazon DB stores for each product.  But the Amazon system just
moves that string it around, formats it, and indexes the words in it.    (014)

The reason why this method works is that Amazon forces any supplier
that wants to sell their products to conform to the Amazon conventions
and database schema.  The sellers have to map their data to the Amazon
categories and abide by Amazon conventions.  But the suppliers have
total control over how they design or describe their own products.    (015)

That's an example that works.  Now let's consider an example that
might use the Amazon ontology in a slightly different way.    (016)

Suppose that two suppliers A and B have mapped their DBs to the
Amazon schema, and they have both been selling their products
successfully.  But if A and B find a need to share some data among
themselves, they might consider adapting the shared Amazon schema
for that purpose.  Some potential pitfalls:    (017)

  1. The terms A and B share with Amazon about products and categories
     of products are almost completely undefined.    (018)

  2. Since Amazon just uses those terms for classifying and indexing
     what they sell, the customers who read the product descriptions
     use their own language skills to make decisions.  If they notice
     a minor inconsistency in the classification, they use a different
     search term to find what they're looking for.    (019)

  3. But the details of the products are very important for A and B.
     Each company has its own system of classification and its own
     way of designing and describing products.  When A and B map
     their internal categories to the Amazon categories, the mappings
     are almost always many to one.    (020)

  4. But the software and databases of A and B can't adapt the way
     people do.  They can't read and interpret the character strings
     that Amazon presents to their customers.  A unique mapping between
     the categories of A and B might be difficult or impossible to find.    (021)

The issues with the Amazon example plague any shared general ontology.
It can only support interoperability for a limited range of problems
for which it was designed.  The ontology and the URIs that go with it
might be a useful starting point for other applications.  But there
may be so many cross mappings that it could be easier to start over.    (022)

 > I suppose we can make something up, e.g., models M1 and M2 of theory
 > G are inconsistent with each other if there is some sentence A in
 > the language of G (obviously not a theorem of G) to which M1 and M2
 > assign different truth values.    (023)

Yes. I prefer to talk about the set of ground-level facts in a database
as a model of the theory expressed by the conjunction of all the DB
definitions and constraints (axioms).  Whenever you add a new axiom,
you reduce the set of permissible models (i.e., databases) that
that can satisfy that theory.    (024)

> it's the simple logical fact that every consistent incomplete
> theory has consistent extensions that are mutually inconsistent.    (025)

Yes.  The Amazon ontology is consistent and incomplete.  The thousands
of businesses that map to it have consistent extensions that are
inconsistent with one another.  It would be counterproductive for
Amazon to design an ontology that has only one model.    (026)

> it's not obvious that an interesting practical ontology has to contain
> the arithmetic needed to guarantee incompleteness and hence can't be
> complete.    (027)

I doubt that any practical applications use nonstandard models
of arithmetic.  But everybody from Kant to Wittgenstein noted that
you can't state necessary and sufficient conditions for defining
any concepts that arise through common usage.    (028)

You can take a common term, such as 'checking account', and specify
some general definition that is sufficient for electronic funds
transfer.  That is similar to what Amazon does.  But the EFT definition
is *intended* to be sufficiently incomplete to allow different models
for each bank that uses its own software for checking accounts.    (029)

David F
> To transmit a C' or C'' thing as a C thing is a fair substitution;
> but to receive a C thing as a C' or C'' thing does an implicit
> narrowing that is not necessarily valid.    (030)

I agree.  Anything defined in a specialized ontology C' or C'' is
consistent with a general ontology C.  But the converse is not true:
an arbitrary thing defined in C might conflict with the ways that C'
or C'' things are used.    (031)

Doug F
> ... it appears that 'employee' is a class, not a property.    (032)

That is a distinction expressed in different ways in different
notations.  In any case, the issues about URIs and interoperability
are independent of the notation and the metalevel terminology.    (033)

Doug F
> It is unlikely that either company has rules that apply to all employees
> of all companies all over the world -- or even in their local jurisdictions    (034)

That's true, and it strengthens the points I was trying to make.    (035)

Doug F
> This suggests that a communication can be incomplete if
> relevant parts of the context are not transmitted as well.  However,
> by defining contexts and rules within a context, one has the option
> of verifying the constraints upon receipt of information and/or
> transmitting the constraints with a query.    (036)

I agree.  But many people have been told that URIs will solve their
problems.  I just wanted to point out that the problems require much
more analysis and more detailed conventions than just using URIs.    (037)

John    (038)

Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J    (039)

<Prev in Thread] Current Thread [Next in Thread>