api4kb_reasoning
====== 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] (current) 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 | ||
api4kb_reasoning.1363546124.txt.gz · Last modified: 2013/03/17 14:48 by admin
Page Tools
