lookup general information (wiki - dbpedia) get information about what is currently playing (music, video, etc)(dcop/dbus) get similar artists (last.fm) lookup information about files on computer
General
Email
Contacts
rss feeds (google reader API)
browsing history
files saved (text documents, pictures, etc)
personal wiki type filesystem
music
music listen history
videos
Tagging
Logic of all of this
SPARQLOperators
Slightly less trivial:
[if | when | nil] condition [then | nil] action
[do | execute | nil] action [when | on | if] condition
Is it possible to take advantage of property names to build a basic language that has never been seen before?
What are the various types of words used?
How to keep all of the information 'clean'? Data of a specific type can always be found in the same place. The date of an email is always in the date tag, not sometimes in the someoneelse:datetime tag.
- clean it as it comes in?
- when and how is data added to the database?
- email: a client pulling emails from your mailserver
- files: you download them
- configurations: when you tell it to
- functionality: when you ask for it
o use some kind of listener/driver/device
- has a lower level interface
- has a high level interface (added syntax/context building on functionality already available/mashups)
- when and how is data added to the database?
Basic system:
databases: email, rss [feeds], browser history, movies, contacts, schedule, etc
The database must provide a mapping to a base SPARQL query that returns all of related entries.
PREFIX email: <http://simile.mit.edu/2005/06/ontologies/email#>
PREFIX dc: <http://purl.org/dc/elements/1.1/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT ?name ?from ?subject ?date
WHERE
{ ?email email:subject ?subject .
?email email:from ?from .
?from rdfs:label ?name .
FILTER (!regex(?name, "zach dwiel", "i")) .
?email dc:date ?date }
ORDER BY DESC(?date)
Under each database are common basic properties to compare against and how to translate to SPARQL:
from * => ?email email:from ?from . FILTER regex(?from, "*", "i")
from * => ?email dc:date ?date . FILTER (how do I just do the generic today, yesterday, blah: the same way you do my birthday, the release date of Gutsy, etc)
%emails% from %date% => concatenate(%emails%, ?email dc:date ?date . FILTER ?date == %date%)
%emails% from %date 1%[ , | to | , to ] %date 2% =>
need:
basic types:
- {type = ["query" | "data" | "function"]}
- {type = "query", type(query) = "string"}
- when interpreting a query:
- anything inside of %s that match one of the types in the match are substituted directly into the string
- {type = "data", type(data) = "string"}
- when interpreting data:
- anything inside of %s that match one of the types in the match are substituted directly into the string
- {type = "function", type(func) = "string", type(executable) = "function"}
- %s don't get interpreted here. They are passed in as arguments to the function in the order that they are received using the following table layout:
- matchtype - string: name of the type used in the match
- datatype - string: the type of data that is being sent ["query" | "data"]
- data - string: the data passed in from nested english.
- arguments can also be accessed from a vars table:
- if a matchtype is only used once, there will be a variable vars.date for example
- if a matchtype is used multiple times, they will be numbered in order of the match: date1, date2, etc
- the return value can be any of the following:
- nil (might not actually be valid - should a function be required to report on its success?)
- {type = "data", type(data) = "string"}
- {type = "query", type(data) = "string"}
- %s don't get interpreted here. They are passed in as arguments to the function in the order that they are received using the following table layout:
built in functions:
- and(query, ...) : simply merge the queries. This is not always well defined. Don't use this in those not so well defined cases. only select queries can be ored.
- or(query, ...) : UNION the two WHERE clause queries. union the select terms. union the iri and prefix terms. The order of the order by clauses is not defined. Only selects can be ored.