> -----Original Message-----
> From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-
> bounces@xxxxxxxxxxxxxxxx] On Behalf Of John F Sowa
> Sent: Saturday, June 29, 2013 1:16 AM
> To: ontolog-forum@xxxxxxxxxxxxxxxx
> Subject: Re: [ontolog-forum] API4KB and diverse ontologies
>
> Elisa and Benjamin,
>
> When I hear something like that, alarm bells go off in my head: (01)
Then you need to fix your sensor system; they are false alarms. (02)
>
> EK
> > One of the primary goals of the APIs is to provide standard interfaces
> > for constructing hybrid reasoning systems, so that
> > classification-oriented reasoners can be incorporated in a standard
> > way with enterprise quality rule engines, predictive analytics, data
> > mining and other such capabilities to solve real world problems.
>
> To build a hybrid system, you can't just take some random components and
> hook them together with an API. What you need is a systematic
> *framework* -- which includes much, much more than just APIs. And it's
> premature to standardize any kind of framework until *after* you have a
> string of successful applications that demonstrate its value. (03)
No one suggested that some random components would be hooked together with an
API.
Yes, you need a framework. What Davide presented 10 days ago was the
beginnings of a framework -- the draft elements of a description of
capabilities and interfaces. (04)
At each level of interest, an architecture is a definition of functions, a
description of specific components in terms of their functions, and a
specification for the points at which the components interoperate (a set of
interface specifications). The architecture forms the basis for the detailed
specification of a system. But the external interface to a system is not
dependent on its architecture! The external interface specifies the functions
provided by the system "as a whole", or more accurately "as they are to be
provided to clients". The system is externally characterized by the functions
it can provide, at some level of detail, and by the assumptions it makes about
its interactions with a usage environment, including client behaviors. The
external interface is about WHAT the system does, and how you can work with it.
The first-level architecture is about HOW the system implements the exposed
functions in terms of supporting functions assigned to components. But the
first-level architecture is not usually exposed to clients, to say nothing of
more detailed specifications of the system architecture. (05)
The API4KB is about describing WHAT the system can do and HOW the client
interacts with the system to accomplish the advertised capabilities. It is not
dependent on the architecture of the systems that implement it. Since it will
specify a minimal set of required functions, and a foreseeably extensible set
of possible functions that the system might provide, it can be a standard
interface for systems with somewhat diverse capabilities and diverse internal
architectures. That idea has been understood in the software world (under the
term "encapsulation" and others) for at least 30 years. It is, for example, a
fundamental concept in "service-oriented architectures". (And it has been a
fundamental concept in business interactions for hundreds of years. We don't
want to see sausage made, although we may want to know that the process meets
certain standards.) (06)
The intent is that you can use a system that provides the API4KB as a subsystem
in your system. You define the architecture of your system. If your
architecture includes a component with functional capabilities that are
consistent with a capability set that is adequately described by the API4KB,
then you could use the (appropriate variant) of the API4KB as the interface
definition for that component (subsystem). Further, if there are off-the-shelf
tools that provide those capabilities and provide that API4KB interface, then
ANY OF those tools can be plugged into your system as that component. (07)
So let us please not muddy the waters with irrelevant sidebars. If you are
truly ambivalent, give the effort a chance. je vous en prie, laissez faire! (08)
-Ed (09)
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Systems Integration Division, Engineering Laboratory
100 Bureau Drive, Stop 8265 Work: +1 301-975-3528
Gaithersburg, MD 20899-8265 Mobile: +1 240-672-5800 (010)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (011)
>
> Ed cited several companies that have designed products that combine
> multiple components. But those companies did not start with an API.
> They started by building custom-designed *applications* in which they
> developed software that used several different components. After building
> enough applications, they were able to abstract and generalize the
> commonalities and design reusable APIs. But they also had more than just
> APIs. They also had supporting tools and a methodology for using them.
>
> As just one example, look at UIMA. The A is for *architecture*, not *API*.
>It
> does indeed have APIs, but those are part of an architecture that includes
> tools and a methodology for linking and coordinating multiple interacting
> components. IBM demonstrated the potential in that architecture by using it
> in the Watson system.
>
> I'm not recommending UIMA as the ideal architecture, but I would have
> more confidence in the API4KB project if they had discussed it (and/or other
> architectures) -- either positively or negatively.
>
> BG
> > I have a lot of experience with design and implementation of KB/KRR
> > interoperability, which has been a major part of all the systems I've
> > built and released since the mid 90s.
>
> I'm glad that you pushed the button to send your note to the entire Ontolog
> Forum. That kind of experience is essential.
>
> 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
> (012)
_________________________________________________________________
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 (013)
|