UserObservationHub (UOH)

The UserObservationHub - shortly: UOH (pronounced "uh-oh!" ;-)) ist a *tiny* project and service catching several registered user observation notifications (e.g., from ​http://dragontalk.opendfki.de) and passes them on to interested listeners. There are multiple input sources that actually observe the user - these observers are implemented as plugins to applications or as listeners to operating system events. They connect to the User observation hub, or more precisely to collectors which are started together with the user observation hub. Each collector provides a different kind of interface, the differences can be both on communication layer (SOAP, REST, XML-RPC) or on the message layer. Some observers report messages to the collectors using serialized RDF conforming to the NOP ontology, others call methods of a collector and pass information as method arguments. Therefore, multiple collectors exist providing the needed interfaces. Each collector standardizes the input observations to RDF, which is then passed to the user observation hub.

The interfaces of the collectors are, in their respective protocol, similar to this:

/* Collect a reported observation, protocol is REST, message is already in RDF, 
   the rdf can be parsed and passed to the UOH */
RESTCollector.userobservation(String uri, String observationAsRDFXML);

/* Collect a reported Browser Navigate To URL Operation,
   Protocol is XML-RPC, message format is specific to the NOP ontology.
   A RDF has to be created from the parameters, more values of the observation are added
   (such as type of operation and current time) and then passed on to UOH */
eventBrowserNavigateToURL(String currentURI, String toURI);

The UOH receives the operations as RDF messages, the primary method all collectors call is:

/*
  public void fireObservedNopGraph( String nopUri, String modelAsRdfXml );
*/

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

Involved Persons:

• Sven Schwarz (DFKI GmbH, Kaiserslautern) -> for Projects Mymory and Nepomuk
• Leo Sauermann (DFKI GmbH) -> for Project Nepomuk
• Julien Gaugaz (L3S, Hannover) -> for Project Nepomuk
• Gianluca Demartini (L3S, Hannover) -> for Project Nepomuk

Check out the UOH from this SVN repository:

https://usercontext.opendfki.de/repos/trunk/UserObservationHub

Important classes:

• UserObservationHub.java
• UserObservationListener.java

NOP ontology (vocabulary)

The NOP ontology (nop.rdfs) is hosted at these two positions:

• ​http://ontologies.opendfki.de/repos/ontologies/userobs/nop.rdfs <-- the "real" one
• ​https://usercontext.opendfki.de/repos/trunk/UserObservationHub/src/de/dfki/km/usercontext/userobservationhub/vocabulary/nop.rdfs <-- a copy is used by the UserObservationHub
• NOTE: Those two MUST always be synchronized!

Goals:

• Important is, that the input to the UOH is in a language that can be understood by all listerners, i.e, they all should use the same schema for observed NOPS.
• On the other hand, information loss is not really acceptable, that is, down-translating to simple UOH language may remove interesting data.
• The UOH language captures:
  • Native Operations (NOPs), a tree of classes. They are used to express observed user actions, such as navigating in a browser or opening a file.
  • DataObjects, which are a second structure, describe and reference the touched objects, such as files, e-mails, webpages.
• NOPs are the primary information captured, namely what the user did. The UOH vocabulary aims at providing a thorough and exhaustive description of the domain of NOPs.
• Data Objects is not intended to be complete but to be minimal. We acknowledge that other endavours, such as ​NIE (with its more detailled sub-ontologies NCO, NMO, ...) or the W3C ontologies for calendaring are more detailled description of such objects. However, we provide a shared schema to be understood and interpretable by all listeners to a user observation hub, independent of detailled modelling.
• To realize these goals, we require observers to pass on observed user actions using NOP. However they are allowed to describe Data Objects either using UOH/NOP DataObjects or in their proprietary data format.
• The UserObservationHub will translate DataObjects (in any input form) to UOH schema while KEEPING the "native" (richer) data. That means: The incoming NOP contains for example a richer data object modeling. This will then be enriched with the simpler UOH data object modeling BUT the original richer modeling still stays in the RDF. DataObject then may have two types: their original type (for example, NIE:Document) and also the NOP:DataObject type.
• Some translation modules are included in the User Observation Hub (for example for NIE). To model DataObjects with unknown schemes, you must provide a translation module for the UserObservationHub to the UOH vocabulary.

Extending the UOH:

• You may add more subclasses to allow more NOPs or data objects. For example, add a SwitchOnLights NOP.
• You should inform the UserObservationHub team, such that, the new NOP can be included in the nops.rdfs and distributed to other researchers listening to UOH.