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