This WIKI is the work space for assembling responses to the OMG API for Knowledge Bases (API4KB) RFP

• Standard Specification (Google Docs)
• Computable Artifacts and Reference Implementation (GitHub)
• Technical Documentation (GitHub pages)

The API4KB will define APIs for the following:

• Parsing
• Reasoning
• Persistent Storage
• Queries
• Rules
• Meta-querying to understand the capabilities of the service (whatever is behind the API)

Whether there is a complex set of services or a simple back-end with a single ontology and reasoner should be immaterial to API4KBs – we should not necessarily expose applications to the potential complexity if they don't want that

If we want to integrate various reasoning systems in a loosely coupled, hybrid environment, though, we will need integration apis that can allow you to build up these more complex sets of services. Thus, the APIs need to support both levels of development: (1) a very abstract interface to some service, and (2) more complex, lower level apis that provide access to the individual services and allow us to build up more complicated apps from these lower level services.

The proposed solution must support these Use Cases, and it must also support the following architecture styles.

Our list of issues can be found here:

One possible strategy is to use a processing model that takes its inspiration from the eXtensible Access Control Markup Language (XACML). XACML is an OASIS standard that defines a declarative access control policy language that is implemented in XML. It also defines a processing model for how to evaluate authorization requests according to the rules defined in the policies. This strategy would be to keep the XACML processing model, but replace the XACML language with a combination of Web Ontology Language (OWL) and a rule language.

The XACML standard provides a UML interaction diagram of the processing model that we plan to reuse. This diagram is a slightly enhanced reproduction.

In the course of developing the set of APIs the submission team feels are necessary to meet the RFP requirements, we have identified several ontologies that the APIs depend on. These include ontologies describing knowledge base descriptors, asset descriptors, the set of languages used by the relevant knowledge bases and/or tools, and the capabilities of those languages and/or knowledge bases. Each of these are described in more detail here.

• Davide Sottara, Arizona State University, presented Motivations and Directions for API4KB to the meeting of the OMG Ontology Platform Special Interest Group (PSIG) on September 13th 2012
• Davide Sottara, Arizona State University, created Notes From API4KB Working Session to the meeting of the OMG Ontology Platform Special Interest Group (PSIG) on December 13th 2012
• Notes from API4KB Working Session, March 17, 2013
• Presentation to Ontolog PSIG March 21 2013
• June 2013 OMG Update

• Ontology Definition Metamodel
• Draft Specification Metadata OWL file (zipped), including definitions for content type, language, serialization format, to be presented as an OMG AB recommendation in Burlingame, December 2012
• Examples of a REST implementation from CTS2
  • REST Signatures for CTS2
  • Sample CTS2 GET - get all children of class 1532007
  • Sample 2
• Github repo for MagicDraw models
  • API4KB Work in progress - MagicDraw model an older version?

• OntoIOp
• Foundation for Intelligent Physical Agents (FIPA) Abstract Architecture Specification
  • FIPA Ontology Service Specification
• The RDA (Resource Description and Access) Vocabularies
  • RDA Registry
  • RDA Steering Committee and Development Site
  • Summary article about the RDA effort, D-Lib Magazine
  • Open Metadata Registry, Registered RDA Vocabularies
• RIF
  • Overview
  • RIF RDF and OWL Compatibility
• RuleML
  • Primer
  • Deliberation RuleML Version 1.0
  • Reaction RuleML Version 1.0
  • Rule Responder
  • The Abstract Syntax of RuleML - Towards a General Web Rule Language Framework
  • PSOA RuleML API: A Tool for Processing Abstract and Concrete Syntaxes (Preprint Proc. RuleML-2012)
  • PSOA2TPTP: A Reference Translator for Interoperating PSOA RuleML with TPTP Reasoners (Preprint Proc. RuleML-2012)
  • PSOA RuleML Implementation
• OntoMaven
• The Grailog User Interface for Knowledge Bases of Ontologies & Rules
• RESTFul API to RDF
• Graph Query Language
• Eric Prud'hommeaux, W3C, presented SemWeb APIs, discussing, among other things:
  • SPARQL Graph Protocol
  • Linked Data Profile
  • Linked Data API (Jenni Tennison)
• Other W3C Resources
  • SPARQL 1.1 Entailment Regimes
  • SPARQL 1.1 Service Description
• Geoserver An example (SOAP or RESTful) API for a portal:
  • Web Feature Service (WFS) This is the web service standard that is used for CRUD operations for spatially-aware online datastores. It is based on a conceptual model that is specific to geographic domain, and so is not directly applicable to our situation, but does provide a model that may be of benefit.
  • Web Process Service (WPS) This is the web service standard (http://www.opengeospatial.org/standards/wps) that is used for the E operations (of CRUDE) for spatially-aware online datastores. It is sufficiently generic that it could be used directly for specifying processing of any MIME type, including OWL, RDF, Common Logic, etc..
    • The very general WPS is made more specific through Application Profiles. See http://www.gi-days.de/archive/2008/downloads/acceptedPapers/Papers/Nash.pdf for some discussion of strengths/weaknesses of the mechanism for defining such profiles as defined in the WPS specification.
  • Geoserver Overview
  • REST Services in Geoserver
  • Reference (Conceptual) Model used in Geoserver
  • REST framework used in Geoserver: Restlets
  • http://geoserver.org/display/GEOS/GSIP+61+-+WFS+2.0#GSIP61-WFS2.0-SOAP SOAP
• API4KB Metamodel For Heterogeneous Knowledge Platforms