====== Differences ====== This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
api4kb_reasoning [2013/03/17 14:48] admin |
api4kb_reasoning [2013/03/17 15:07] admin |
||
---|---|---|---|
Line 7: | Line 7: | ||
Meta-APIs | 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 | ||
Line 18: | Line 19: | ||
* 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 | * 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 ===== | ===== Questions ===== | ||
* Enter questions here | * Enter questions here |