Hi Ed --
You wrote...
Logically, from two tables that involve the same key value, e.g.
R1(a,b) and R2(a, c, d), what we can conclude is "R1(a,b) AND
R2(a,c,d)". Using Codd's algebra, we can generate Rx(b,c,d), but we
have no idea what the meaning of Rx is. In database manipulations the
semantics of Rx is in the mind of the engineer and the algebraic formula
is an algorithm for realizing the satisfying tuples. Now, we can indeed
assume the existence of a common basic logic grammar and its semantics,
with the consequence that we will know what logical manipulations of
these relations are truth-preserving. But the semantics of any of the
relations is still in the heads of the engineers.
There is actually a solution for this. Instead of writing R1and R2, use meaningful English sentences as table headings. When you combine R1 and R2, again use a meaningful English sentence for the combination, instead of the semantically opaque "Rx".
In this way, the semantics in the heads of engineers is shared with others who will use the knowledge and the computations.
As you may know, there's a system online at the site below that supports this approach. The system explains its results, in English, at the business or scientific level -- even it the results were gotten by running automatically generated SQL. It's able to do this because the semantics were captured from the engineers' heads at knowledge input time.
Cheers, -- Adrian
Internet Business Logic
A Wiki and SOA Endpoint for Executable Open Vocabulary English over SQL and RDF
Online at www.reengineeringllc.com Shared use is free
Adrian Walker
Reengineering
On Wed, Jan 7, 2009 at 7:38 PM, Ed Barkmeyer <edbark@xxxxxxxx> wrote:
Neil Custer wrote:
> Two ideas I'll float to see if they make any sense whatsoever:
>
> - With so many viewpoints of an ontology's construction and purpose: Pick
> one benefit and push the construction methodology to the limit to further
> that particular benefit--perhaps some other natural benefits may fall out as
> side effects.
I think this is an interesting "engineering experiment", as long as it
comes with some success metric. That is: If you know what benefit you
want, define an objective criterion that determines whether you have
achieved some part of that benefit. Now, do indeed choose and use an
ontology engineering methodology, and see if and when it results in
satisfying that criterion. And be prepared for the methodology to fail,
or to need significant additions or modifications to succeed. Then
please report on it.
The trick with something like this is to (have the leisure to) take a
scientific view of the activity as an experiment. The experimental
result may support or contradict the benefit hypothesis, and EITHER
result is equally important.
The problem with most real software engineering activities is that they
must succeed, and the methodology will be (publicly or secretly)
modified as needed to achieve some modicum of project success. And at
the end, it behooves no one to report that the chosen methodology failed
(typically because it is perceived to lay blame on the individuals who
chose it).
(We successfully demonstrated that a 6th Framework technology could be
used to solve a practical problem as long as cost/benefit was not a
consideration. Of course, it was only politically correct to publish
the first half of that.)
> - Determine a way to express the ontology construction aspect as an
> ontological type based on its purpose/benefit. Then determine methods for
> these to interact (or more particularly, describe the relationships between
> them).
I don't understand this.
> It seems illogical to me to try to capture all knowledge in a single
> ontology, just as it is ridiculous to capture all facts about a domain in a
> single flat-file "database".
You are not alone.
> My thinking is that when a single ontological
> discourse can be captured in something as basic as a table in a database and
> can be related to other tables in a knowledge domain as easily as building
> primary keys between tables in a database, then the ability to use the
> information contained in a set of domain ontologies will take off at an
> unbelievable pace.
I have many problems with this. That which is as simple as a table in a
database is a logical relation. Each row captures a single "fact"; a
set of occupants of the columns (roles) for which the relation maps to True.
It can be related to other tables only as long as everyone agrees that
the occupants of the columns denote the same things. In Neil's terms,
every table designer agrees that these are primary keys and on what
thing each key value denotes. My experience is that once you get past
nonnegative integers that count things, the agreement on the denotations
of most key values is restricted to a small user community. (There is
however wide use of a handful of standards that name individuals:
countries, languages, organizations.)
We might have a better chance of agreeing on the denotations of the key
values if we could agree on the meanings of the names at the tops of the
columns, or even the meaning of the name of the table, but alas, we find
it very difficult to get such agreement over any but local communities.
Logically, from two tables that involve the same key value, e.g.
R1(a,b) and R2(a, c, d), what we can conclude is "R1(a,b) AND
R2(a,c,d)". Using Codd's algebra, we can generate Rx(b,c,d), but we
have no idea what the meaning of Rx is. In database manipulations the
semantics of Rx is in the mind of the engineer and the algebraic formula
is an algorithm for realizing the satisfying tuples. Now, we can indeed
assume the existence of a common basic logic grammar and its semantics,
with the consequence that we will know what logical manipulations of
these relations are truth-preserving. But the semantics of any of the
relations is still in the heads of the engineers.
So, the more fragmented the knowledge model, the less useful it is. It
takes mutual understanding to integrate it with anything else. The more
you have already integrated, the more problems can be solved using your
ontology. OTOH, the more you have already integrated, the more
philosophies and assumptions you require a user to accept. And that may
make it much harder to integrate with other useful ontologies. So this
seems to follow the Diamond Principle: A little fragmentation is good.
Too much fragmentation is debilitating, and too little fragmentation
is oppressive and brittle.
> I've been exposed to teams that have been building enormous XML schemas with
> the intent of modeling all possible uses for all of the data they may want
> to exchange in an enterprise
And that approach is so clearly ill-led and doomed to failure that you
should avoid excessive exposure to it, much as you would UV radiation.
> I perceive a similar situation has risen in this forum for trying to
> find an ontology approach that meets all knowledge engineer's needs and is
> hitting up against this same conundrum.
Well, as far as I can tell, that quest is the Holy Grail of only one
quixotic knight.
The original question was: what should be the relationship between
ontologies and the many existing and emerging standard information
models and dictionaries that support standards of practice?
-Ed
--
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/
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 (01)
|