====== 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 | ||