SWiM/service interface

Specification of an interface that services can use to communicate with SWiM, which shall be an integrated platform for services.

Objective
All ../services shall use this interface and the vocabulary defined by the upper document ontology – instead of being hacks. (It's not sufficient that, e.g., MathWebSearch in itself is kind of ontology-based. Its communication with SWiM must also be ontology-based!) Only this way the whole thing gets scalable (think of OMDoc 2.0) and portable (think of CNXML or sth. else).

Work plan

 * formalize a few services to get a feeling for the requirements of the service API
 * anything that's specified as "input" or "output" in a service specification must be made accessible through the service API

From SWiM to Service

 * get current page/concept (as RDF resource)
 * only the ID, or an object?
 * Generic RDF wrapper object or classes generated at compile time from the document ontology (e.g. OMDocTheory)?
 * get dependencies of current page
 * query arbitrary RDF triples (for auto-completion and dependency graph (learning assistance))
 * if editing OMDoc/XML: get current source code and cursor position
 * note: that need not be valid XML during editing!
 * later: user model

From Service to SWiM

 * write a "bookmarking" record to a special table (for learning assistance)

Compile-time vs. run-time
Note that not all services might need run-time access to the knowledge base in terms of the document ontology. Some services (e.g. the syntactical auto-completion) might only require compile-time "linking against" the ontology. (In the former case, not even the ontology, but only the XML schema.)