| 27 | | Multiple output listeners getting notified about the operations, called "user observation listners". The multiple input listeners support application-specific communication protocols and interfaces. Depending on the application that was extended with a user-observation plugin, and the programming environment that determines how the plugins are created, the |
| | 29 | As the name indicates, the UOH receives messages and notifies other components about them. The listeners can be registered with the UOH on startup. All registered listeners are called in sequence. |
| | 30 | |
| | 31 | == Message format and mapping == |
| | 32 | The passed messages often consist of two parts: |
| | 33 | * What native operation was observed? This has to be described using the NOP ontology and captures the class of operation, time, and application used. |
| | 34 | * On what data object (file, e-mail, webpage, etc) did the operation work? This can be expressed using NOP, which only provides basic classes for data objects, or other vocabularies. |
| | 35 | |
| | 36 | Before passing the RDF message to the listeners, a '''mapping of ontologies''' is done. |
| | 37 | |
| | 38 | The NOP ontology focuses to describe the domain of native operations. '''Data Objects''' is not intended to be complete but to be minimal. We acknowledge that other endavours, such as [http://www.semanticdesktop.org/ontologies/nie/ NIE] (with its more detailled sub-ontologies NCO, NMO, ...) or the W3C ontologies for calendaring are more detailled description of such data objects. However, the NOP Data Objects provide a simple schema to be understood and interpretable by all listeners to a user observation hub, independent of detailled modelling. |
| | 39 | To realize a standardization of vocabulary, we require observers to describe and pass on observed user actions using NOP's native operation classes. However they are allowed to describe Data Objects either using UOH/NOP DataObjects or in their proprietary data format. |
| | 40 | As output, the original input messages will be passed on, with data objects transformed to NOP's dataobject vocabulary if needed. So the UOH is liberal in what it accepts and conservative in what it passes on. |
| | 41 | |
| | 42 | The UserObservationHub will translate DataObjects (in any input form) to UOH schema while '''keeping''' the "native" (richer) data. For example, the incoming NOP contains a richer data object modeling representing an e-mail using NIE. The message will then be enriched with the simpler UOH data object modeling but the original richer modeling is not removed but remains in the RDF model. A DataObject then may have two types: their original type (nmo:Email in the example) and also the DataObject type (nop:Email). |
| | 43 | |
| | 44 | Classes providing such a mapping have to implement a special interface (MappingToNop) and can be registered as modules with the User Observation Hub. |
| | 45 | For NEPOMUK's NIE ontology, such a mapping was implemented. It is based on the Jena rule engine and uses horn clauses to generate the additional data in the UOH vocabulary based on data objects represented in NIE. User who want to extend the implementation and pass RDF messages using other vocabularies to express DataObjects, they must provide a mapping module for the UserObservationHub to the UOH vocabulary. |
