Ed and Adrian,
>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.
> (01)
The main reason Codd's algebra is not suitable for constructing ontology and in
general for sharing knowledge - is not that operators like "join" are opaque.
Main reasons are soundness, decidability and computability of any relational
algebra. I am not an expert to provide specific references, but I know enough
to understand why Description Logic is considered to be the only practical
framework for sharing knowledge. This had been discussed on this forum many
times, often comparing Prolog and OWL as representing competing alternatives
for encoding knowledge. The jury is still out on it, I think.
But is should be clear that simply translating SQL to English is not a viable
approach. (02)
>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
>>
>>
> (03)
_________________________________________________________________
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 (04)
|