Following is a note to the OOR list. But the general principles
are also relevant to this thread on Ontolog Forum. (01)
John (02)
-------- Original Message --------
Subject: Re: [oor-forum] OOR Team Meeting
Date: Tue, 25 Jun 2013 14:19:12 -0400
From: John F Sowa
To: oor-forum@xxxxxxxxxxxxxxxx (03)
On 6/25/2013 9:55 AM, kenb wrote:
> Davide Sottara presented API4KB at an Ontolog meeting last year. See
>
> http://ontolog.cim3.net/cgi-bin/wiki.pl?ConferenceCall_2012_11_08#nid3HJO
>
> The slides are at
>
>
>http://ontolog.cim3.net/file/work/OntologyBasedStandards/2012-11-08_Ontology-based-Standards-II/API4KB_API-for-Complex-Knowledge-Bases--DavideSottara_20121108.pdf (04)
Thanks for the references. I did not listen to the audio, but I
compared Sottara's slides from 2012 (URL above) to his slides from
an OMG presentation in March 2013: (05)
http://www.omgwiki.org/API4KB/lib/exe/fetch.php?media=api4kb-sottara-20130321.pdf (06)
I must say that I preferred the older slides. They discussed the
problems and challenges of trying to get heterogeneous KBs to
interoperate. And they showed that the problems are nontrivial. (07)
But the 2013 slides focused on proposed solutions, which I seriously
doubt are workable. Slide #2 makes a very bad assumption: (08)
> Problem: Provide uniform access to Knowledge Bases (09)
If you attempt to provide uniform access to heterogeneous KBs that were
designed for different purposes, assumptions, and levels of granularity,
you will get garbage. Just look at slide #3: (010)
> Composite KBs :
> ● Ontologies (T-box + A-box)
> ● Rulebases (Rules + Facts)
> ● Predictive Models (Models + Datasets)
> ● Business Processes (Processes + Instances) (011)
If the same group developed all four KBs on the same subject, they
would probably be compatible -- and they could probably use and reuse
much or all of the same ontology. But if four different groups
developed four such KBs on the same general topic, I would bet that (012)
1. They could interoperate with a very vague upper-level, such
as the extremely underspecified Schema.org. (013)
2. But any reasoning done at a more detailed level in any of those
four KBs would not be consistent with similar reasoning at a similar
level of detail in any of the others. (014)
3. However, it would be possible for general *results* of an inference
performed in one of the four KBs to be exported for use by another
KB. Example: one of the KBs might use special-purpose techniques
to locate addresses based on limited info about a person. That KB
could export the resulting address without being able to share most
of its internal knowledge or its methods of reasoning. (015)
Slide 5 shows an attempt to micromanage the reasoning process: (016)
> API Categories
> ● Parsing & Translation
> ● KB Construction
> ● Query
> ● Reasoning
> ● Meta (017)
First of all, parsing and translation depend on low-level syntactic
details. Any knowledge sharing should be independent of syntax. (018)
For the other four points, just consider a merger between two banks,
both of which use SQL databases, have similar kinds of clients, and
have similar kinds of accounts. (019)
Many bank mergers have occurred during the past 20 years or so,
but *none* of them merged their databases. In every case, they
continued to run both DBs indefinitely -- and transfers from
one DB to another of the merged bank were processed *as if*
they were going to and from independent banks. (020)
If you can't depend on knowledge sharing among SQL DBs that are
owned and operated by the same organization, can you seriously
believe that sharing among more complex KBs would be easier? (021)
Just imagine trying to share anything at a detailed level between
Cyc, Watson, SUMO, and the Rulelog system that Benjamin Grosof
discussed last week. (022)
Kinds of knowledge that could be shared: (023)
1. The results of reasoning expressed as low-level facts
(i.e., something closer to RDF than to OWL). (024)
2. Underspecified definitions at the level of Schema.org. (025)
3. More general information that was derived by some fairly
complex process, such as Formal Concept Analysis (FCA)
or the kinds of techniques that are being developed by
the Ontoiop project. (026)
In all three cases, the *results* of some extended processing are
being shared -- not the details of the original sources or methods. (027)
John (028)
_________________________________________________________________
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 (029)
|