UserObservationHub (UOH)

The UserObservationHub - shortly: UOH (pronounced "uh-oh!" ;-)) ist a *tiny* project and service catching several registered user observation evidences and notifications (e.g., from ​http://dragontalk.opendfki.de) and passes them on to interested listeners. So, there's multiple input sources to the UOH providing observed user operations and multiple output targets getting notified by the UOH -> these are "user observation listners".

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

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.