[Top] [All Lists]

Re: [ontolog-forum] Next steps in using ontologies as standards

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Ed Barkmeyer <edbark@xxxxxxxx>
Date: Wed, 07 Jan 2009 19:38:03 -0500
Message-id: <49654AEB.1000805@xxxxxxxx>
Neil Custer wrote:    (01)

> 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.    (02)

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.    (03)

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.    (04)

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).    (05)

(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.)    (06)

> - 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).      (07)

I don't understand this.    (08)

> 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".     (09)

You are not alone.    (010)

> 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.    (011)

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.    (012)

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.)    (013)

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.    (014)

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.    (015)

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.    (016)

> 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    (017)

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.    (018)

>  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.    (019)

Well, as far as I can tell, that quest is the Holy Grail of only one 
quixotic knight.    (020)

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?    (021)

-Ed    (022)

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    (023)

"The opinions expressed above do not reflect consensus of NIST,
  and have not been reviewed by any Government authority."    (024)

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    (025)

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