> <mailto:
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