John F. Sowa wrote:
> EB:
>
>> are you disagreeing with the assertion that the translation is
>> difficult/impossible?
>>
>
> The question is translation from what to what. To translate any
> of the popular ontology/modeling languages to Common Logic (or
> the IKL extension) is neither difficult nor impossible. In fact,
> it's hard to find any common notation that *cannot* be translated.
> (01)
Then we disagree. It is my impression that capturing the semantics of a
language like ORM in CLIF requires some significant effort to develop a
set of enabling relations. Terry Halpin's thesis makes explicit use of
proposition nominalization (IKL 'that') with the appropriate constraints
(Henkin) that allow it to have a first-order model. But that doesn't
make the first order model easy to formulate or easy to comprehend.
Further, all of the closed world assumption stuff that permeates the
semantics of conceptual schema propositions strikes me as needing
special support in a FOL rendition. (02)
I find it much easier to agree that it is possible to construct a formal
semantics for a conceptual schema language, and not to be deeply
concerned about its relationship to a first-order semantics. In a
similar way, there are formal semantic models for logic programming
languages, and few people really care how they relate to first-order
semantics. The purpose of these languages is to enable the use of
particular kinds of reasoning engines to solve particular application
problems. In general, one would not use a first-order reasoner like
Otter/Prover9 to determine database consistency/integrity, or transform
a Prolog program to first-order axioms. The theoretical foundation may
tell me that such a transformation is possible, but it has no use. (03)
My tenet in all of this discussion is that Sjir's desire to compare
conceptual schema capabilities with first-order ontology capabilities
per se is apples and oranges. But Sjir does raise a valid question:
Show us an explicit business application that a comprehensible
first-order ontology, or an OWL/DL model, and its associated reasoning
engines can solve and that a conceptual schema and its associated
reasoning engines cannot solve. That is an entirely different
question, and it is one we must answer if we are to sell ontology as a
true improvement on 'information modeling'. (04)
What we are seeing in industry to some extent is that people who never
understood conceptual modeling, and people who are just being introduced
to the idea, are being taught that OWL is a means of capturing the
concepts you meant in your XML schema, and it frees you from having to
describe relationships by tree structures and untyped pointers. That is
a great step forward. And the fact that they are actually rediscovering
the state of knowledge engineering in 1990 should not be a cause for
concern (except that education in 'computer science' allows this kind of
ignorance to occur regularly). It will gradually sell the concept
'ontology' in the industrial marketplace, and that is good. Yes, John
will be disappointed/annoyed that this new generation of information
modelers is hallowing OWL, but it is much better than the last 10 years,
in which information modelers used XML Schema (thereby repeating the
ASN.1 experience of the 1980s, which fortunately got less press). The
greater danger is that in 2012 some modernized version of a crude
modeling practice from 1972 will become the latest-and-greatest W3C
standard, and OWL will be denigrated. (05)
The DAMA people discovered that conceptual modeling only ever influenced
a small group of expert data analysts in the 80s and 90s. So they
renamed it "business modeling" and "business rules" to get management
attention, thereby increasing the community by one order of magnitude,
from insignificant to barely visible. Consultants know about these
technologies, and they use them in executing the services they provide,
but they are selling their services, not the technology. Sjir is
indirectly asking us to avoid the same fate, by knowing what it is we
can do for industry, and selling that, as the technological advantage. (06)
> But I would agree that translating one special-purpose notation
> to another special-purpose notation may be difficult or impossible.
> (07)
That is not the issue. (08)
> But if you translate both to CL, you can state rules in CL for
> relating their common subsets and providing ways of accommodating
> those aspects that don't have one-to-one translations. (09)
Yes, you can construct bizarre first-order ontologies to convey
non-first-order concepts. But it is nearly impossible to use a
first-order reasoner to do anything useful with ontologies like that.
It is usually better to lose the concepts you can't easily express. The
point is that we don't ever want to suggest that this theoretical
possibility is helpful in solving real application problems -- it is
easier to use the tools for which that kind of 'ontology' was designed. (010)
> I discuss
> the issues about "knowledge compilers" in the following article:
>
> http://www.jfsowa.com/pubs/fflogic.pdf
> Fads and fallacies about logic
>
>
>> The main difference, however, is that these conceptual schema
>> languages have a semantic model based on a closed world assumption
>> -- that the information base is a 'model', not just the rest of
>> the ontology -- and in most cases they have some intrinsic notions
>> that are non-monotonic.
>>
>
> There are many different, but related ways of handling non-monotonic
> and the CW and OW assumptions. My recommended version is one that
> Alan Robinson (and others) proposed many years ago: treat them
> as theory revision methods. See below for an explanation.
> (011)
More of same. The semantics are importantly different, but we have
theoretical work-arounds. Yes, we do, but we don't apply reasoning
engines to the theoretically transformed models to get results. This is
academic logician stuff, not practical knowledge engineeering. (012)
> EB:
>
>> [The ANSI/SPARC conceptual schema] was a technical architecture
>> for database specification. All the rest is window dressing.
>>
>
> Some DB people had a very narrow view, but many others had a much
> broader view. During the 1980s, I participated in an IFIP working
> group on databases chaired by Robert Meersman. That group included
> some dedicated logicians and AI people, and we organized a series of
> conferences on Data Semantics that invited speakers like Dana Scott,
> John McCarthy, Ray Reiter (and even me). Many people in that group
> participated in writing the 1987 ISO report on the conceptual schema.
> (013)
Yes. That is, a different group of people produced a different
technical report that described conceptual modeling. (014)
I stand by my statement: the 3-schema architecture is about data
systems engineering, not conceptual modeling. In the 3-schema
architecture, the term "conceptual schema" means the database schema
that integrates all the application views and describes the logical
(relational) structure of the actual database.
This contrasts with "external schemas", which are "views" of the
database that are presented to specific applications, and the "internal
schema", which is the technical data structures that implement the
"conceptual schema". To borrow from Jack Ring, these two uses of the
string "conceptual schema" are homographs that have some overlap in meaning. (015)
The ISO Reference Model for Data Management (ISO 10032:1993?)
generalized the idea of "conceptual schema" to be what ISO TR9007 means
by the term -- a form of ontology divorced from particular data
architectures. The RMDM idea is that the integration of viewpoint
models is conceptual and results in a conceptual model that is
unburdened by concerns of data representation, organization, and access
efficiency. The implementation of the "integrating conceptual model"
can be a single "conceptual schema" of the ANSI kind, in which case,
there is a derivation relationship that should be formally documented.
But it could also be a set of databases, each having its own "conceptual
schema", which is treated as a view of the integrating conceptual
model. In such a case, there is a formal mapping from the conceptual
model to the database conceptual schemas, and that mapping supports the
operations of distributed database tooling. (NIST and U. Florida built
one of those in the 1980s.) (016)
So John is correct that the "conceptual schema" idea from the ANSI
3-schema architecture did not satisfy the ISO folk and ISO altered the
meaning of the term to a definition that was more acceptable to John and
the ANSI/SPARC DBSSG. And OBTW, the ISO TR9007 group was the successor
to the ISO group that produced TR8002 (with the same title) in 1984.
Sjir Nijssen was one of the (leading) members of the earlier ISO group. (017)
(My business has been information technology standards for 30 years, and
the meaning of a term in a given standard is important to us picky
standards people. One would think, however, that the meaning of a term
in context would be very important to knowledge engineers in general.) (018)
> JFS:
>
>>> No matter how big the upper level may be, it can only contribute
>>> a small part of the total that is needed for any significant application.
>>>
>
> EB:
>
>> I don't know whether we agree here or not. If the application ontology
>> is the "lower level", then it can be pretty small. Most of those I have
>> had to build have had about 150 classes and 300 properties. The problem
>> is that 120 of the 150 classes are primitive.
>>
>
> That depends on how much of the semantics you intend to specify.
> I have always maintained that a great deal of the semantics needed
> for interoperability can be defined with a type hierarchy and very
> few axioms. Two programs might use the same data in very different
> ways, and neither one knows anything about what the other one does
> with the data.
> (019)
The problem is knowing whether it is the same data, and the taxonomic
approach only works if the communicating applications agree on the
taxonomy. I agree that formal statements of the properties that A
assigns to X and the properties B assigns to X may not have much
overlap. But there must be some overlap, else there is no reason for A
and B to use the same objects. So the two have to agree on a set of
common properties and those properties have some axiomatic nature. Now,
it may be that each level of John's taxonomy associates a single
property to the instances of the classifier it defines, but even then
you have at least as many properties as there are classifiers. As I
said, in my experience, the ratio is about 2-to-1. On the other hand, a
full-blown supply-chain ontology, a la AIAG MOSS, has 500 classes and
2000 properties -- the difference is that some of the classifiers
(party, order, item, shipment) can play a lot of roles and have a lot of
relevant properties. (020)
> EB:
>> To make the ontology more useful, you need to produce definitions
>> of most of the classes and properties, and that requires a much
>> richer and clearly founded middle layer. I see my ontology as
>> a hut with multiple levels of sub-basement.
>>
>
> Yes. And all those levels for every application can require
> a very large amount of specification that can overwhelm what
> is in the hut.
> (021)
Yes. We agree. (022)
On a historical note, John wrote: (023)
> My (personal) goal had always been to focus on the semantics in a form
> that could support any and every special-purpose notation. When I
> first started attending the X3H4 meetings, I was working at IBM, and
> I avoided any statements that conflicted with official IBM policy.
> (024)
ANSI X3H4 ("Data Dictionaries and Models") was one of the examples of
owner interference with standardization of a conceptual schema
language. And the ISO activity that it "tagged" was a UK-originated
proposal for representing a "conceptual schema" (of the ANSI kind) as an
SQL model. Many members of that committee were later involved in the OMG
Meta-Object Facility standard of 1998 -- the four MOF meta-levels come
from the ANSI data dictionary standard X3.138. I think that John and I
would agree that that body, as a whole, aimed low. Tammy Kirkendall was
the NIST lead, and she and I (re)wrote the ANSI X3.138 data dictionary
exchange file specification, because it used ASN.1 (an XML precursor),
and I was the NIST expert on ASN.1. (025)
> But when I participated in the conceptual schema subgroup, I was
> actively proposing a logic-based semantics in a form that could
> support any and every vendor's syntax. In 1992, I persuaded
> Mike Genesereth and Richard Fikes (the authors of the KIF report)
> to attend the SC32 meeting in Florida to begin a project on
> developing parallel standards for KIF and conceptual graphs. (026)
And I was the NIST principal in X3T2 ("Information exchange standards"),
which is where Mike and the would-be KIF standard went. X3T2 in 1990 was
the scene of the failure to standardize a form of NIAM. X3T2 was later
absorbed into INCITS L8 ("Metadata repositories"), which is now the U.S.
"TAG" for the ISO committee that owns Common Logic, and other unrelated
work. (027)
This is as much as I am willing to do of the Maurice Smith "you can't
tell the standards players without a program" talks. (028)
And one other bit: In 1984?, I took an actual course in information
modeling from CDC, and it was my first real encounter with the
technology. The guy who taught it was Sjir Nijssen! Suffice it to say
that John, Sjir and I have been on collision courses for years. :-) (029)
-Ed (030)
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 (031)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (032)
_________________________________________________________________
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
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (033)
|