1 files changed, 0 insertions, 106 deletions
diff --git a/doc/context-cron.txt b/doc/context-cron.txt
deleted file mode 100644
index c26f4a09..00000000
--- a/doc/context-cron.txt
+++ /dev/null
@@ -1,106 +0,0 @@
-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.
-  }