Changes between Initial Version and Version 1 of UserContextOntology/Discussion

Timestamp:

06/19/08 17:41:09 (16 years ago)

Author:

sauermann

Comment:

--

UserContextOntology/Discussion

@@ +1 @@
+= Discussions that lead to the creation of the UserContextOntology =
+
+2007-09-21: Leo Sauermann and Sven Schwarz sit together and make a draft of the ontology for nepomuk.
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+