| 16 | | 2007-09-21: Leo Sauermann and Sven Schwarz sit together and make a draft of the ontology for nepomuk. |
| 17 | | |
| 18 | | 2006-08-23: Sven |
| 19 | | |
| 20 | | eigentlich ist doch eine "ContextEntity" ein "ContextSubject" - oder? |
| 21 | | und die "ActiveEntities" wären eigentlich "ContextProvider" oder sowas |
| 22 | | dann hätten wir sowas hier: |
| 23 | | {{{ |
| 24 | | ContextSubject -> Context information *about* these are possible |
| 25 | | - Person -> we may know about a person's context |
| 26 | | - Device -> we may know about a device's context |
| 27 | | - ... |
| 28 | | |
| 29 | | ContextProvider -> These *provide* context information |
| 30 | | - Person -> a person may provide context (manually) |
| 31 | | - Device -> e.g. a GPS device provides context |
| 32 | | - ... |
| 33 | | |
| 34 | | ContextObject -> Objects and data in some context |
| 35 | | - Person -> some person may be relevant for another person's context |
| 36 | | - Device -> e.g. an input device may be relevant for a person's context |
| 37 | | }}} |
| 38 | | |
| 39 | | Phil: das passt, nur andere Worte. ContextProvider ist bei uns ContextTracker |
| 40 | | |
| 41 | | ---- |
| 42 | | |
| 43 | | == Current status == |
| 44 | | |
| 45 | | * Phil is discussing with his Prof. -> http://www.piranesi.dyndns.org/mediawiki/index.php/Talk:ContextOntology |
| 46 | | |
| 47 | | * Sven is creating first drafts of base-level and mid-level context ontology in RDFS. |
| 48 | | |
| 49 | | - Browse the current status with a web browser using this URL: https://usercontext.opendfki.de/browser/temp/uco_v1 |
| 50 | | |
| 51 | | - Or check it out using SVN using this URL: https://usercontext.opendfki.de/repos/temp/uco_v1 |
| 52 | | |
| 53 | | |
| 54 | | ---- |
| 55 | | |
| 56 | | == Phil's short memo about it (older, directly after MRC'06) == |
| 57 | | |
| 58 | | |
| 59 | | Context ontology |
| 60 | | |
| 61 | | What is the purpose: |
| 62 | | |
| 63 | | The goal is to create a context ontology describing a wide range of user context attributes and the relation ships between them. |
| 64 | | 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. |
| 65 | | |
| 66 | | Generic reasoning is performed on the high level context ontology and through the extensions more specific reasoning is made possible. |
| 67 | | How much "domain knowledge" needs to be present in the higher level? |
| 68 | | |
| 69 | | |
| 70 | | INTERFACES: |
| 71 | | The extension interface needs to be well defined. |
| 72 | | |
| 73 | | 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 |
| 74 | | purpose a strict extension policy is required. |
| 75 | | 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 |
| 76 | | framework extensions, as well as a syntax checker making sure the extensions can be integrated into the high level structure. |
| 77 | | |
| 78 | | For Bluetooth the RDF extension would look something like the following: |
| 79 | | |
| 80 | | <rdfs:Class rdf:about="&kb;Bluetooth" |
| 81 | | rdfs:label="Bluetooth"> |
| 82 | | <rdfs:comment>Bluetooth is a short range communicaiton device which can also be used to detect other Bluetooth devices in short proximity</rdfs:comment> |
| 83 | | <rdfs:subClassOf rdf:resource="&kb;Communication_Device"/> |
| 84 | | <rdfs:subClassOf rdf:resource="&kb;Sensor_Device"/> |
| 85 | | </rdfs:Class> |
| 86 | | |
| 87 | | 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 |
| 88 | | a small xml description of e.g. sensing frequency and power consumption. Enabling the application builder or other reasoning engines to understand device specific |
| 89 | | capabilities which do not affect the general use of the extension. |
| 90 | | |
| 91 | | <rdfs:Class rdf:about="&kb;Bluetooth_Scanner" |
| 92 | | rdfs:label="Bluetooth_Scanner"> |
| 93 | | <rdfs:subClassOf rdf:resource="&kb;Bluetooth"/> |
| 94 | | <rdfs:subClassOf rdf:resource="&kb;Proximity_Location"/> |
| 95 | | <rdfs:subClassOf rdf:resource="&kb;Software"/> |
| 96 | | </rdfs:Class> |
| 97 | | |
| 98 | | 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 |
| 99 | | to show dependencies or is this just done through subclasses? |
| 100 | | |
| 101 | | |
| 102 | | Reasoning engines: |
| 103 | | |
| 104 | | We need at least two types: one for queries and one for the application builder. |
| 105 | | |
| 106 | | What are good existing engines? |
| 107 | | |
| 108 | | How can a reasoning engine adopt dynamically to the extensions? |
| 109 | | It could for example just use a Bluetooth device to find close entities. Is this good enough or does it need to know more? |
| 110 | | |
| 111 | | Possible queries: |
| 112 | | |
| 113 | | Who is near me? |
| 114 | | Through proximity sensors and reasoning about the location of other entities. |
| 115 | | |
| 116 | | Where am I? |
| 117 | | Through location sensors and through devices in close proximity which know their location. |
| 118 | | |
| 119 | | Problems: |
| 120 | | Proximity: how to define proximity? Should entities performing a query be able to specify what it means to them? |
| 121 | | 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? |
| 122 | | This requires to be able to associate confidence values with query results. |
| 123 | | Also the time to live indicators need to be handled correctly in order to place any confidence on them. |
| 124 | | |
| 125 | | |
| 126 | | |
| 127 | | |
| 128 | | A list with the different terms and definitions would be very useful. |
| 129 | | |
| 130 | | |
| 131 | | Definition of context. Anind.... Richard had another one which is very similar but coming from another direction. |
| 132 | | |
| 133 | | context-aware |
| 134 | | |
| 135 | | context memory / history |
| 136 | | |
| 137 | | |
| 138 | | |
| 139 | | Context attribute |
| 140 | | |
| 141 | | Context listener: can register to or poll new context attributes and passes them on to an application |
| 142 | | |
| 143 | | Context tracker: takes a context attribute from a sensor or application and places it into the context store. |
| 144 | | |
| 145 | | 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 |
| 146 | | a context tracker and listener. |
| | 15 | The discussions involved in creating the ontology can be found here: |
| | 16 | * UserContextOntology/Discussion |
