Semantic Web calendaring
I will be talking about a Semantic Web vocabulary for describing
events, and in particular
-
what it's for, and
-
how we went about creating one
and hopefully ...
-
a bit about why the Semantic Web is both interesting and useful
Why create a Semantic Web vocabulary for events?
A workshop, October 2002 in Bristol, UK on the Semantic Web and
calendaring:
Personal information disaster
To try to solve the personal
information disaster
-
scattered schedules in HTML, XML, iCalendar, proprietory (and binary)
formats in public and private places, none easily searchable or combinable
-
copying and pasting from webpages to PDAs, and between formats and devices
-
errors in schedules leading to missed meetings, missed opportunities
-
a general inertia about scheduling since finding out if you are busy
is such an effort
- people getting irritated by this, and saying:
Wouldn't it be great if it was easy to find out what's happening (and
in particular, what I'm supposed to be doing)? Why
do I have to do this stuff that my computer could do for me?
Connections between events and other things
Everything is connected (lots of things are, anyway)
- events link people with other people, documents, pictures, places,
restaurants...
It would be good to be able to find useful and interesting links
between events and other things automatically. Why can't my
computer do this for me?
Events and people
-
who is coming to this meeting? in what way are they 'expert'? what else
have they written or spoken about? what do they look like?
Events and geographical information
-
where am I going? how do I get there? where's the nearest
{restaurant|hotel|station|...}?
What do we need to do...
-
to find the things that are events?
-
to find the things that are events that are in a certain location?
-
to find the things that are events that my friends are attending?
-
to find the things that are events that interest me/are about a certain
topic/that my boss says I should attend?
We would like a way of describing, publishing and searching with
precision events with these sorts of characteristics, where the
events can be created by many different individuals and tools.
Vocabularies for events, people, places....
- a single vocabulary for events cannot convey all the information we
would like to have about events, people, places, documents
-
...and shouldn't try to
-
experts in any particular field are probably the best people to write
vocabularies for that field
-
agreement on vocabularies takes lots of time
-
agreement with experts from different fields takes even more time
Much better is to be able to combine vocabularies easily and
devolve the creation of vocabularies where possible.
Why RDF?
RDF (Resource Description Framework) has a model for combining many
different vocabularies created independently
-
RDF has objects (people, documents, events, locations) and their properties
(name, identifier) and relationships (attendee, knows, created)
-
RDF Schema and OWL can be used to document how these objects and
properties relate to each other in a 'schema' or 'ontology' (a
reuseable, machine-readable vocabulary)
-
RDFS and OWL can also be used to make connections between different
vocabularies (subclass, domain, range)
-
RDF (sometimes enhanced with OWL) can be used to merge information about
things from different sources: different descriptions of the same object
can be combined together
RDF is designed for combining vocabularies describing
overlapping domains of interest, and for merging, storing and searching data
defined in this way.
Creating an RDF vocabulary for events
There is already a standard! - RFC 2445 -
iCalendar...but
-
it doesn't do what we want in terms of mixing people, places etc with events
-
it is difficult to extend
-
it is long and difficult to understand (events, especially repeating events
are complex to model)
-
it is difficult to work out the authors' intentions in some cases
iCalendar in RDF: the wrong way
Reusing existing expert work, and taking into account that
many implementations use iCalendar, but:
- using the pondering approach: sitting and thinking == translating from
one format to another with incomplete information
-
why was this modelling decision made rather than another?
what did the authors mean by X?
- first
pass: many uncertainties and possible contradictions
- decisions made in translation were often arbitrary and themselves
ill-documented
RDFCal: the right way
A different approach: a
syntactic conversion of iCalendar to RDF
- implementation and testcase driven
- testcases from iCalendar generated by existing tools (Mozilla
calendar, Apple iCal, Evolution) and usecases (restaurant opening hours,
bus timetables, conferences)
- vocabulary (schema) generated automatically
from accepted testcases
- virtual meetings and email discussion about modelling problems
- vocabulary consistent with established usage
- implementations
- paper trail
- roundtripping to iCalendar, and....
interesting talks with developers too
Creating RDF event data
Finding and creating events are related: to create an event, you need to
know what other events are occuring at similar times and dates
-
creating events by converting iCalendar data
- linking events by applying certain types of rules to aggregations of
data using owl:inverseFunctionalProperty
-
creating RDF events through specialized tools
Returning to the usecases
Our initial usecases were:
- finding out what's happening (to me)
- finding interesting links between events and other things
We are doing this using off-the-shelf RDF tools (e.g.
using Jena, RDFLib, Brownsauce, Joseki; also other experimental ones) to
-
search aggregations of RDF event data
-
make this data accessible to other tools (e.g. via http)
-
display events and the things they link to
An event creation tool demo
An event creation tool
-
lightweight - uses 'RESTful' web services to access information from
several different sources
- what's happening today? what am I supposed to be doing today?
-
creating events with locations, keywords, people...
We don't have all the answers...
Issues:
- identifying events: events don't have URIs
- datasource intelligence: start and finish - what about the middle?
- privacy: many events are private and must stay that way
- trust: who says I'm going to this meeting? who said I was there?
More information
Thanks for listening!