This is surely a number one contemporary problem with many solutions. However, what about the poor folks out there who do not speak English regardless of how it is encoded back and forth?
Debbie MacPherson
On 6/20/07, Adrian Walker <adriandwalker@xxxxxxxxx> wrote:
Ed, John --
Sorry to jump into the discussion a bit late.
Ed wrote...
The highest price, and the
one most often paid in languages like KIF, is that your model will fail to
communicate your understanding to your target audience, because no one can
easily "grok" the model as formalized.
John wrote...
There are often good reasons for inventing new notations,
but it would be helpful to make them interoperable and
automatically translatable to anybody's favorite human
or machine-oriented notation.
If we harden John's comment a bit, then we have a very strong candidate notation. It's called English,
and it allows humans to interoperate. Unfortunately, it's very
hard to get software to understand it in a way that is both completely
natural and also useful in practice.
However, there are (at least) two approaches to bridging the
English-to-software gap. It's my understanding that John favors
automatic translation between logic and a tiny controlled subset of
English, as in his project and the EU's Attempto.
Our experience with that approach is that it's fine in the research
lab, but to put it bluntly, it does not seem to scale. People
expect larger and larger subsets of English, non-grammatical and jargon
usage, and so on. The result is an overwhelming dictionary
and grammar maintenance task.
In our online system [1], we make a radical trade off to get to enough
executable English for folks to "grok" what's going on, and yet we
avoid the dictionary and grammar maintenance task. This allows us
to support the writing and running of practical applications, such as
oil industry supply chain planning [2], in which the authors of the
executable English use their own words and phrases. The supported
English has place holders for variables such as "some-refinery" and
"a-location" but is otherwise open vocabulary and largely open
syntax. It's not as natural as we would like (but neither is
legal English, or medical English...), but so far we don't know of any
way of making it more natural without falling into the
dictionary-grammar tar pit.
Many folks still prefer to write OWL or Java or whatever, and to
keep a separate set of English comments to document what they
meant. But as we keep rediscovering, that opens up a semantic
grand canyon, not to mention what happens when the code is changed but
the comments are not.
With apologies to folks who have seen similar arguments before.
Cheers, -- Adrian
[1] Internet Business Logic
A Wiki for Executable Open Vocabulary English
Online at www.reengineeringllc.com Shared use is free
[2] www.reengineeringllc.com/Oil_Industry_Supply_Chain_by_Kowalski_and_Walker.pdf
Adrian Walker
Reengineering
On 6/20/07, Ed Barkmeyer <edbark@xxxxxxxx> wrote:
John,
you wrote:
> Ed,
>
> I certainly agree with that point:
>
> > The highest price, and the one most often paid in languages
> > like KIF, is that your model will fail to communicate your
> > understanding to your target audience, because no one can
> > easily "grok" the model as formalized.
>
> But the SemWebbers succeeded in making KIF look readable by
> inventing the most unreadable formats ever inflicted upon
> a significant number of users.
Amen! For XML folk, the concept "human-readable" seems to mean "expressed in
characters, most of which may be interpretable as words in some natural
language", regardless of whether the words have any relationship to the
conventional meanings or the structure represents any speech pattern that any
human understands.
RDF is only "human-readable" with that definition.
And making OWL RDF-compatible makes OWL-as-written very hard for humans to
grok, even though the concepts are quite comprehensible.
It is my personal view that RDF and its children were really intended only to
be read by specialized software tools, and some of those tools might
reasonably be 'ontology editors' that present the ontology in a form that is
easier to work with. And in the spirit of free enterprise, the toolsmiths are
free to choose forms, styles and interfaces that are ergonomic and create
market. (That is what happened with HTML and XML Schema and ASN.1, for
example.) Further, in the environment in which OWL was developed, there were
already many tools that supported most of the OWL concepts and already had
their own established notations. It would have been much harder to get a
standard notation that sent every existing DL implementation back to the
drawing board for ontology editing -- they had enough trouble
incorporating/fixing the missing/broken reasoning features.
But creating a plethora of proprietary human-readable representations has a
major drawback on the "education and training" front: No standard
ergonomically human-readable representation means *no standard basis for books
and courses*. You don't want to teach children to model in RDF/OWL with
pointy brackets and absurd designators; you want to teach them to model in
something like CGIF or ORM, which they can understand, and for which everyone
agrees on the notation and its meaning. But we need a (de facto) standard
ergonomic notation in which there is a well-defined standard 1-to-1 mapping to
the standard language concepts and their XML exchange representation.
The Protege representation is fine as far as it goes, but it is not (quite)
1-to-1 with OWL/DL and it is at best the leading candidate for de facto
standard. Conversely, the OMG representation of OWL as a specialization of
UML modeling is accidentally widely implemented by UML tools that have no
concept of its meaning and therefore no implementation of the mapping to the
OWL exchange representation. And the traditional users of UML are a different
audience. So it is not clear that the OMG representation, international
standard though it may be, will ever be the de facto standard on which
training materials are based.
Success in modeling languages obeys the "Anna Karenina Principle"*: Happy
families are all alike; every unhappy family is unhappy in its own way.
Regards,
-Ed
* The original is a translation from the Tolstoy novel, but Jared Diamond, in
"Guns, Germs and Steel", refers to it as the "Anna Karenina Principle" -- the
explanation for the success of one system and the failure of similar systems:
many different factors must come together to create success; any one missing
factor can cause failure.
--
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 FAX:
+1 301-975-4694
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority."
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config:
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 Post: mailto:
ontolog-forum@xxxxxxxxxxxxxxxx
_________________________________________________________________
Message Archives:
http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: 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 Post: mailto:
ontolog-forum@xxxxxxxxxxxxxxxx
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: 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 Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (01)
|