Re: SUO: should a standard specify...
Hi Jim,
Quoting from: http://suo.ieee.org/email/msg08333.html
> I face some practical problems that I hope you can help me with.
I cannot solve all your problems for the moment, but there are
a few points I want to make about your questionning.
> Faced with hundreds of megs of terms, definitions, comments, relations,
> axioms, and so forth, how can I comb through these ontologies to
> do the following?
I hope the "hundreds of megs" will at last lead someone to seek
for *realistic* automated solutions.
> How to get the relevant ontological primitives and assertions from the
> ontology itself?
In order to "understand" the content of any ontology you have to have
a description of it's syntax and semantics, even for "hand-carving".
> It seems that interoperability always comes at some price, such as
> agreement on certain conventions. From recent postings to the list, one
> price people seem ready to pay is that of agreeing on a particular
> logical language.
Which has yet to be defined.
> What I want to suggest is that the assumption of a common language for
> expressing different ontologies may not be realistic, at least not at the
> present time. (See, for example, the discussion below of "thing" in SUMO,
> Cyc, and ISO15926-2.)
You are assuming because the word "thing" is used with different meanings
by different people/specifications it is impossible to find a "true" meaning.
You are right in that the meaning is not and *cannot* be the same, but you
are wrong in assuming that to make sense of interoperability between such
different contexts you have to reconcile the meanings based on syntactical
identity or even similarity of the symbols used. A SUMO thing, a Cyc thing
and an ISO15926-2 thing need *not* have the same meaning.
> What I want further to suggest is that maybe what is needed is not so much
> an agreed-upon common language, but an agreed-upon method to identify in
> a given ontology what are the primitive entities, relations, axioms, and
> definitions, and how these primitives can be used to extract
> domain-specific subontologies. Perhaps such an agreed-upon method should be
> part of the ontology's specification. Such a method would certainly help in
> the examples below.
Such an "agreed-upon method" is obviously dependent of the *target*
"common logical language" which is yet to be defined. This might be CL but
I see no reason for a more easyly reached (and sensible...) agreement
on CL than on SUO.
> To put it metaphorically, how can two ontologies, who happen to find
> themselves on a street corner checking each other out, assess each other's
> goods and whether or not they might be able to have a meaningful
> encounter together? The mere fact that they speak the same language may
> help, but something more is needed I think. It is this something more
> that I am suggesting bears consideration.
Consider how long it took for Champollion to make sense of the Rosetta Stone:
http://www.chesco.com/~cslice/aurora/rosetta/rosetta.html
and how tedious it has been:
http://www.stanford.edu/~thare/regypt/Rosetta/rosetta3.html
Then you expect that ontologies "who happen to find themselves on a street
corner" will be reconciled by some process *without* some common semantic
grounds, however small this may be (I do think it can be *very* small).
You can as well ask for the ontology broker to have "psychic" capabilities
that will be a *real breakthrough* in AI!!!
> I want to find those components of the different ontologies that bear
> on, say, naive spatial relations. But even before I try to extract those
> components, I'll probably need to understand something very general: how do
> Cyc, SUMO, and ISO1596-2 treat the notion of "thing" or "entity"?
Exactly, but this has to be given a *formal* definition.
> So, I looked in each of these ontologies for "thing" and "entity".
> What follows are some results, which don't pretend to be exhaustive.
>
> Cyc has ( at http://www.cyc.com/cyc-2-1/vocab/fundamental-vocab.html#Thing ):
> ------------------------------------------------------------------------------
[snip]
> ------------------------------------------------------------------------------
>
> SUMO has:
> ------------------------------------------------------------------------------
> (documentation Entity "The universal class of individuals. This is the root
> node of the ontology.")
>
> ;; Everything is an entity (due to Robert E. Kent).
>
> (forall (?THING) (instance ?THING Entity))
> ------------------------------------------------------------------------------
>
> The ISO15926-2 draft, in clause 5.2.1.1 (with the underscore fore
> and aft added by me to indicate bolding in the document), has:
> ------------------------------------------------------------------------------
> A _thing_ is anything that is or can be thought about or perceived,
> including material and non-material objects, ideas, and actions. Every
> _thing_ is either an _individual_, a _class_, or a _relation_.
>
> [a NOTE is ommitted here]
>
> EXPRESS specification:
> ---------------------
>
> *)
> ENTITY thing
> ABSTRACT SUPERTYPE OF (ONEOF (class, individual, relation));
> id : STRING;
> UNIQUE
> UR1 : id;
> END_ENTITY;
> (*
> ------------------------------------------------------------------------------
BLA, BLA, BLA...
> How are people or programs to deal with such variability?
It is not so much the variability than the *lack of content* of
these so-called definitions that is the problem.
An ID is an ID, period. Any "meaning" it takes come from the rules
that are specified to operate on and between the IDs.
> (In a sense, perhaps, what I'm looking for is a sort of generic ontology API
> that would allow me to gather the relevant ontological primitives for a
> particular domain. Ideally, such an API would allow programs to automatically
> assess different ontologies for compatability, based on only a small set of
> seed primitives.)
That's about what I propose, it has yet to be defined.
> As far as the SUO effort is concerned, I suggest that we consider whether
> the identification of and access to certain ontological primitives, as well
> as the means to use those primitives for extracting domain-specific
> subontologies, should be part of the standard.
I beg to differ. Why the heck is everybody so keen to slap yet another
layer of API/specs/primitives onto an existing structure each time a
specific need arise?
Cannot you deal with the already present capabilities built in the structure?
There must be some, otherwise there would not even be any structure to be seen.
> ------------------------------------------------------------------------------
> SUMMARY
>
> * I see some difficult practical issues of how a human or a machine
> can determine whether (certain subdomains of particular) ontologies
> stand a chance of being able to interoperate with (certain subdomains of)
> other ontologies.
That does not seem to have been noticed by many people pushing for
an "agreement" on SUO.
> * The main difficulties seem to be: (1) how to identify the relevant
> ontological primitives (e.g., terms, definitions, axioms) used by an ontology;
> and (2) how to use these primitives to extract a particular domain-related
> portion of the ontology.
Why would you want to do (2)?
If the ontology is there why not just use it?
> * Being able to identify, extract, and manipulate these primitives _seems_
> key to being able to assess whether two ontologies can interoperate
> (in virtually any plausible sense of that word). But it may indeed not be
> appropriate to suppose that one could determine whether two ontologies
> can interoperate based on accessing the ontological primitives and
> assertions used by the ontologies to talk about a particular domain.
> To those who hold this view, can you please elaborate?
I did partly already, are you sure you read carefully enough and
extracted all the info available?
In other words can you elaborate on your questions if you want
more detailed answers.
> * Currently, as shown by the examples of SUMO, Cyc, and ISO15926, different
> ontologies have different ways of representing these primitives, and in many
> cases it is difficult to determine from the ontology itself, how these
> primitives are identified and can be made available. Currently, these
> determinations must be done manually (I think) and in an ad hoc way.
> Perhaps the SUO standard can address how to accomplish make such
> determinations programatically.
Exactly. This requires a "common" description convention for both the
syntax and semantics that could be applied to *all* such formalisms.
And this is DIFFERENT FROM YET ANOTHER COMPETING formalism within the
same domain. It does NOT have to be used for anything else than describing
the other formalisms, just like EBNF versus a specified language.
> * It is possible that a single, agreed-upon ontology language will go a long
> way in helping to identify and make available these ontological
> primitives and the subsequent extraction of domain-specific subontologies.
> But it seems that some specific mechanism that is different from a
> common language, and which belongs perhaps to the ontology's specification,
> needs to be provided. Such a mechanism needs to be, well, mechanical -- capable
> of being done by a machine with limited sets of seeded input.
Right.
> * What that mechanism is, what the ontological primitives are, and how
> this mechanism can be used in practice to identify and make available these
> primitives and to allow certain subontologies to be extracted -- I suggest
> that all this should perhaps be investigated in the context of our
> standards work.
Great! Some real work going to be done at last...
> * If these issues have already been addressed and solutions for them
> have been found, please let me know.
I expect that if "solutions" where there someone would know...
Any "hidden" and successful research conducted somewhere else in the galaxy?
Cheers.
-- Jean-Luc Delatre
--------------------------------------------------------------
"Start at the Beginning, go through till the End, then stop."
- King of Hearts, from "Alice in Wonderland"
--------------------------------------------------------------
http://perso.club-internet.fr/jld/ -- GSM: +33 6 11 24 06 29