====== Differences ====== This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
api4kb_reasoning [2012/10/01 15:38] rmbell created |
api4kb_reasoning [2013/03/17 15:07] (current) admin |
||
---|---|---|---|
Line 1: | Line 1: | ||
APIs for reasoning [[start|Link to API4KB Main Page]] | APIs for reasoning [[start|Link to API4KB Main Page]] | ||
* Check for logical consistency, satisfiability | * Check for logical consistency, satisfiability | ||
+ | * Check for deductive closure (if appropriate) | ||
+ | * Provide basic classification (subsumption, identity reasoning) | ||
+ | * Provide / identify inferred facts, and materialized in the knowledge base, indicate which are inferred | ||
+ | * Explanation support | ||
+ | |||
+ | Meta-APIs | ||
+ | * Supported languages, formats | ||
* Provide metrics, similar to what is done today for Protégé | * Provide metrics, similar to what is done today for Protégé | ||
* Provide indication of reasoner capabilities | * Provide indication of reasoner capabilities | ||
* how expressive | * how expressive | ||
* what operations are supported | * what operations are supported | ||
- | * Check for deductive closure (if appropriate) | + | |
- | * Explanation Support | + | Additional Requirements |
- | * Provide subsumption and identity reasoning at a minimum (DL), inferred facts, and indicate which are inferred | + | |
* Support both batch and dynamic interfaces | * Support both batch and dynamic interfaces | ||
* e.g., assertion/retraction of facts at run time | * e.g., assertion/retraction of facts at run time | ||
* Support for multiple reasoners, kinds of reasoning | * Support for multiple reasoners, kinds of reasoning | ||
* e.g., DL, DL approximation (such as TrOWL), various OWL profiles, OWL “Full” with punning, RDF entailment | * e.g., DL, DL approximation (such as TrOWL), various OWL profiles, OWL “Full” with punning, RDF entailment | ||
+ | * semantic profiles e.g. different entailment regimes | ||
+ | |||
+ | |||
+ | So, looking at the requirements: we would like to build a KB | ||
+ | incrementally, check its consistency and either confirm or undo some of | ||
+ | the changes. I don't see anything that | ||
+ | mandates the transactional approach. The consistency check should not be | ||
+ | a problem: | ||
+ | |||
+ | ***** CheckConsistency( | ||
+ | in URL knowledgeBase | ||
+ | out boolean isKBConsistent ); | ||
+ | REST mapping : POST | ||
+ | |||
+ | (Apparently trivial API, but we should define what "consistent" means in | ||
+ | the general case vs pure ontology KBs) | ||
+ | ===== Questions ===== | ||
+ | * Enter questions here |