1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
|
Context Cron Architecture Study
===============================
The Context Framework allows clients a view into the current state of
the system. Clients can watch that state and react to it
appropriately. Doing this, however, requires a running process
somewhere.
The Context Cron is a component that can be programmed to watch the
system on behalf of other components. Conceptually, the Context Cron
constantly evaluates a set of expressions, and if the value of a
expression changes, the actions associated with that expression are
executed.
Input to the expression can come from various sources:
- context properties,
- settings,
- content queries,
- and the current time.
There are two options for writing expressions, and we should select
one of them:
- All input could be mapped into RDF and SPARQL would be used to
write the expressions.
- SPARQL is extended so that context, settings, and time can be used
as parameters in places where SparQL allows literals.
The latter appears to allow more natural expressions. Mapping the
rich values of context properties into RDF leads to covoluted graphs
that are tedious to query.
In general, it is not wrong to say that the Context Cron adds rich
life queries to the Content Framework.
When ever the result of a expression changes, Context Cron triggers
the associated actions. Actions can be:
- execution of a shell command,
- sending of a D-Bus message or signal,
- changing the value of a context property.
The D-Bus message or signal can include the old and/or new value of
the expression. Shell commands can read a representation of the
values from stdin, in a number of formats.
Actions are specified in a ad-hoc syntax, maybe XML.
Queries can be 'armed' or 'unarmed'. A action only triggers when it
is armed, and triggering a action unarms it. You need to explicitly
arm it again once the action is done, or more generally, once you are
ready for the next trigger.
Queries can be added to Context Cron by dropping files into a
well-known location, or via a D-Bus interface.
Context and Settings Ontology
-----------------------------
Context properties and settings are key/value pairs. The values range
over the "representational types" described in the Desktop Types
document. That document also describes how the values map into RDF
triples.
Context properties are mapped into RDF as triples of the form
"context" <key> <value>
Settings are also key/value pairs with the same value range as context
properties. They are mapped into triples like so:
"setting" <key> <value>
[ XXX - do this properly, using Turtle and namespace and everything.
]
In addition to this generic ontology that makes all context properties
and all setings available to SparQL, there might also be specific
context ontology that is better integrated with Nepomuk.
For example, there is a node "CurrentLocation" with predicates
"nlo:latitude" and "nlo:longitude".
Examples
--------
Create a new context property Location.NearPOIs whose value is a list
of the currently near points of interest, sorted from closest to
farthest. "Near" is defined to mean "can be reached in less than 1
minute with the current velocity."
SELECT ?poi
WHERE
{
?poi nlo:latitude ?lat;
nlo:longitude ?lon.
context Location.Latitude ?curlat;
Location.Longitude ?curlon.
}
|
