api4kb_reasoning
====== 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 | ||
api4kb_reasoning.1349120297.txt.gz · Last modified: 2012/10/01 15:38 by rmbell
Page Tools
