User Context Ontology

A top-level RDF Schema for modeling and processing user context. Besides mere user context *data* the UserContextOntology will also provide operators and comparators for that data. Hence, two parties can share their user context data and will be able to understand and process the user context information at least on the upper level we define here.

---

Diskussion

2006-08-23: Sven

eigentlich ist doch eine "ContextEntity" ein "ContextSubject" - oder? und die "ActiveEntities" wären eigentlich "ContextProvider" oder sowas dann hätten wir sowas hier:

  ContextSubject -> Context information *about* these are possible
   - Person      -> we may know about a person's context
   - Device      -> we may know about a device's context
   - ...
      
  ContextProvider -> These *provide* context information
   - Person       -> a person may provide context (manually)
   - Device       -> e.g. a GPS device provides context 
   - ...
      
  ContextObject   -> Objects and data in some context
   - Person       -> some person may be relevant for another person's context 
   - Device       -> e.g. an input device may be relevant for a person's context

Phil: das passt, nur andere Worte. ContextProvider ist bei uns ContextTracker

---

Current status

• Phil is discussing with his Prof. -> ​http://www.piranesi.dyndns.org/mediawiki/index.php/Talk:ContextOntology

• Sven is creating first drafts of base-level and mid-level context ontology in RDFS.

• Browse the current status with a web browser using this URL: ​https://usercontext.opendfki.de/browser/temp/uco_v1

• Or check it out using SVN using this URL: ​https://usercontext.opendfki.de/repos/temp/uco_v1

---

Phil's short memo about it (older, directly after MRC'06)

Context ontology

What is the purpose:

The goal is to create a context ontology describing a wide range of user context attributes and the relation ships between them. The top level ontology needs to be abstract enough in order to hold for a wide range of different context "models" and to describe more detailed ones it needs to be extendable through well defined interfaces.

Generic reasoning is performed on the high level context ontology and through the extensions more specific reasoning is made possible. How much "domain knowledge" needs to be present in the higher level?

INTERFACES: The extension interface needs to be well defined.

We could take the analogy of microformats which are small semantic descriptions of components, they are mainly used for semantically linking blogs. They are often used stand alone, but for our purpose a strict extension policy is required. A context microformat should be written in the same language as the high-level description, e.g. RDF. A well defined blueprint should be provided to the creator of the framework extensions, as well as a syntax checker making sure the extensions can be integrated into the high level structure.

For Bluetooth the RDF extension would look something like the following:

<rdfs:Class rdf:about="&kb;Bluetooth"

rdfs:label="Bluetooth">

<rdfs:comment>Bluetooth is a short range communicaiton device which can also be used to detect other Bluetooth devices in short proximity</rdfs:comment> <rdfs:subClassOf rdf:resource="&kb;Communication_Device"/> <rdfs:subClassOf rdf:resource="&kb;Sensor_Device"/>

</rdfs:Class>

Stating that Bluetooth is a Communication_Device and a Sensor_Device, as well as optional comments aimed at the human user. This field could contain a small xml description of e.g. sensing frequency and power consumption. Enabling the application builder or other reasoning engines to understand device specific capabilities which do not affect the general use of the extension.

<rdfs:Class rdf:about="&kb;Bluetooth_Scanner"

rdfs:label="Bluetooth_Scanner">

<rdfs:subClassOf rdf:resource="&kb;Bluetooth"/> <rdfs:subClassOf rdf:resource="&kb;Proximity_Location"/> <rdfs:subClassOf rdf:resource="&kb;Software"/>

</rdfs:Class>

Bluetooth_Scanner is the software which needs to be invoked to get a proximity location. The RDF description shows that it "depends" on Bluetooth hardware??? ask Sven if there is a way to show dependencies or is this just done through subclasses?

Reasoning engines:

We need at least two types: one for queries and one for the application builder.

What are good existing engines?

How can a reasoning engine adopt dynamically to the extensions? It could for example just use a Bluetooth device to find close entities. Is this good enough or does it need to know more?

Possible queries:

Who is near me? Through proximity sensors and reasoning about the location of other entities.

Where am I? Through location sensors and through devices in close proximity which know their location.

Problems: Proximity: how to define proximity? Should entities performing a query be able to specify what it means to them? Chain of reasoning: When for example a device in close proximity cannot provide a location but it is close to another one which can --- is that too far? This requires to be able to associate confidence values with query results. Also the time to live indicators need to be handled correctly in order to place any confidence on them.

A list with the different terms and definitions would be very useful.

Definition of context. Anind.... Richard had another one which is very similar but coming from another direction.

context-aware

context memory / history

Context attribute

Context listener: can register to or poll new context attributes and passes them on to an application

Context tracker: takes a context attribute from a sensor or application and places it into the context store.

Context aggregator: takes n number of context attributes as input and outputs n number of new context attributes. It can be viewed as a combination of a context tracker and listener.