====== Differences ====== This shows you the differences between two versions of the page.
Both sides previous revision Previous revision | |||
api4kb_reasoning [2013/03/17 14:53] admin |
api4kb_reasoning [2013/03/17 15:07] (current) admin |
||
---|---|---|---|
Line 19: | 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 |