Changes between Version 4 and Version 5 of UserContextOntology


Ignore:
Timestamp:
06/19/08 17:47:46 (9 years ago)
Author:
sauermann
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • UserContextOntology

    v4 v5  
    11= User Context Ontology = 
    22 
    3 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. 
     3A top-level RDF Schema for modeling and processing a user's work context. Besides mere user context '''data''' the UserContextOntology also provides 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. 
    44 
    5 == Context representation (draft) == 
     5== User Work Context representation == 
     6 
     7The resulting ontology can be found here at its namespace 
     8 * [http://ontologies.opendfki.de/repos/ontologies/wcon/workcontext#] 
    69 
    710Input: 
    811 * [http://epos.opendfki.de/repos/epos/trunk/epos_context/model/context_all.rdfs context_all ontology from epos] 
    912 
    10  
    11  
    12 ---- 
    13  
    1413== Diskussion == 
    1514 
    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. 
     15The discussions involved in creating the ontology can be found here: 
     16 * UserContextOntology/Discussion 
    14717 
    14818 
     
    15222 
    15323 
    154  
    155  
    156  
    157  
    158  
    159  
    160  
    161  
    162  
    163  
    164  
    165  
    166  
    167  
    168  
    169  
    170  
    171  
    172  
    173  
    174  
    175  
    176