SWiM/service interface

From MathWeb

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.)