First of all, an apology to Till Mossakowski et al. I called the OntoIOP
project "InterIOP" (which is actually the name of a long-since failed project).
(01)
Some further discussion below...
(02)
> -----Original Message-----
> From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-
> bounces@xxxxxxxxxxxxxxxx] On Behalf Of John F Sowa
> Sent: Wednesday, June 26, 2013 4:16 PM
> To: ontolog-forum@xxxxxxxxxxxxxxxx
> Subject: Re: [ontolog-forum] API4KB and diverse ontologies (was: RDF and
> XML)
>
> Ed,
>
> I think that we both agree on the general principles.
>
> As I said in my previous note, I liked the API4KB slides from 2012 because
> they gave a few examples of working systems. They talked about gathering
> use-cases. That's a important prerequisite.
>
> But the API4KB wiki and the slides from March 2013 do not cite any examples
> of working systems or any use cases of any kind -- either derived from
> working systems or from Gedanken experiments. That is a sign of a
> *research* proposal, not a candidate for a standard.
(03)
Oh. I fully agree that this is a product of researchers and not a standard
based on industry use. Let me see, now, would that aptly characterize RDF,
OWL, SPARQL and Common Logic when they were standardized? And perhaps SQL as
well? There is no shortage of forerunner projects, whether the website shows
that or not. It is the scope of API4KB, in seeking to support more than a few
of them, that must give one pause.
(04)
I know of several industry projects that unload engineering information into
RDF triple stores, so they can use some off-the-shelf academic SPARQL tool for
an interface. Conversely, there are tools that accept SPARQL queries against
"rote lifted" SQL schemas and then turn them into SQL queries, thus providing
meaningless RDF access to SQL databases. And the real problem is that these
are not all academic projects -- it is what happens when you hire recent Ph.D.
and Dipl-Inf. persons into industry jobs where the boss has heard that RDF or
OWL is the next silver bullet. API4KB involves people whose formal KBs are in
UML+SQL and OWL and Z and assorted production rule systems.
(05)
> the API4KB slides showed that they were ignoring some
> fundamental problems. I'll repeat an excerpt from my previous note:
>
> JFS
> > 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:
> >
> >> Composite KBs :
> >> ● Ontologies (T-box + A-box)
> >> ● Rulebases (Rules + Facts)
> >> ● Predictive Models (Models + Datasets) ● Business Processes
> >> (Processes + Instances)
>
> The underlying semantics and pragmatics in these four kinds of systems are
> represented and used in radically different ways. There are working
> examples of systems of these four kinds that have *started* with some
> common ontology. That kind of sharing can be and has been done.
(06)
If you attempt to provide uniform access to three RDF KBs that were designed
for different purposes, assumptions and levels of granularity, you will also
get garbage IF you use the interface blindly with no awareness of the intent of
the KBs. That is a valid concern for Linked Open Data, perhaps, but it is
irrelevant to the question of providing a standard interface, or a standard
conversion service. The diversity of intent and viewpoint in RDF KBs does not
invalidate the standardization of SPARQL. Why then should the fact that the
languages may be different invalidate the standardization of a common API?
(07)
You make the assumption that there is something intrinsic in the choice of
language for these different KBs. I think you will find that that variance is
as much about history as it is about purpose. Industry gets married to a lot
of hammers. No one denies that the nature of the inferences that can be made
from different kinds of KBs is different. But for the user, the question is
whether a given KB can answer a given question, assuming that there is some
common basis for understanding the question. Yes, it is entirely possible
that there will be a misunderstanding of the query, or that the intended
interpretation of the result is not the interpretation the user makes. But
that can happen if you merge two CLIF ontologies and fire up Vampyre, too.
The relationship between KB mechanics and query intent is always fraught with
the problems of terminological reference and hidden assumptions (what Prof.
Hyunbo Cho called the "unknown knowledge" that is, sometimes unconsciously,
employed in interpretation). That is indeed made worse by the KB language when
it results in circumlocutions and other artifices, but a heterogeneous KB only
makes the likelihood of linguistic interference with intent greater; it does
not, of itself, make the problem any worse.
(08)
>
> There are also examples of systems that been built from scratch to be
> compatible with the semantics of previously implemented systems.
> That is called *legacy re-engineering*. It's not easy, but it can be and has
> been done.
>
> But we have *zero* examples of independently developed systems of these
> four kinds that have successfully extracted their implicit ontology and
>shared
> it a form that could be used by the others.
(09)
Who is "we"? As my father-in-law used to say, I wouldn't want to mention any
names, but their initials are "TopQuadrant" and "CambridgeSoftware" and
"Thematix", and that comes just from reading the badges at OMG meetings whilst
listening to product descriptions. And certainly you must be aware of other
projects that have married new OWL ontologies or production rulesets to lifted
SQL schemas. API4KB is at the leading edge of commercial products in the area,
yes, but it cannot be long before the IMOS gang of four becomes visible with
products in this area as well. They are just letting the startups test the
market.
(010)
> As I said, API4KB would be a reasonable research proposal, but without even
> a *seedling*, it's not a candidate for a standard.
(011)
And as I said, that same argument applies to most of the stuff that W3C has
produced in the last 15 years as well. IT standards bodies, John, are no
longer about standardizing common practices in industry, if they ever were.
The purpose of some of them is to enable a research technology to be used under
industrial rules; the purpose of others is to prevent certain large firms from
controlling a market with a proprietary de facto standard, especially when it
is a hyped but shaky technology. Finally, the purpose of some 'research
standards' is to prevent the production of 5 such standards for essentially the
same thing. I think the API4KB falls into this last category. It will be
ignored, of course, in the inevitable attempt to unify all KBs using RDF or
OWL, the futility of which will take another 5 years to become well-known.
(012)
-Ed
(013)
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Systems Integration Division, Engineering Laboratory
100 Bureau Drive, Stop 8263 Work: +1 301-975-3528
Gaithersburg, MD 20899-8263 Mobile: +1 240-672-5800
(014)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority."
(015)
>
> John
>
> __________________________________________________________
> _______
> 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
>
(016)
_________________________________________________________________
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 (017)
|