• SparqlCalendarDemoUsage

The SparqlCalendarDemo uses SPARQL to query RDF and non-RDF data sources regarding calendar events, shared interests, and the intersection of the two. Several parts of the demo rely on conventions adopted in lieu of widely accepted solutions to particular problems.

The demo, which can be accessed online or downloaded consists of the following steps. (Another step-by-step guide along with demo URIs can be found in this blog entry.) (Anuncio y guía en español)

If you are having (security) problems with the demo, please read the #FAQ below.

1. Input one or more URLs into the box in the top right of the page and click Add. Each URL added in this manner becomes a default graph contributing to the RDF Dataset for subsequent queries. The show loaded URLs link displays the default and named graphs currently being used for SPARQL queries. 2. When a URL is added, the People section of the righthand panel is updated via a SPARQL query that searches the current dataset for foaf:Persons and displays them. The demo performs a bit of smushing on these query results, combining resources that share the same foaf:mbox or foaf:mbox_sha1sum. 3. Clicking the refresh link in the Calendars section of the righthand panel performs a query for all calendar events in the month displayed on the left for the currently selected (checked) people.

• Convention. In lieu of a standard predicate associating a foaf:Person with their calendar data, the demo searches for any rdfs:seeAlso relationships of the form p rdfs:seeAlso u such that p is a foaf:Person and u is a URI with rdf:type http://www.w3.org/2002/12/cal/icaltzd#Vcalendar. (This may be a conflation of a URI with the data at that URI?)

• Convention. The demo allows for calendar URIs to point to RDF data or to iCalendar format data. If the latter, the SPARQL query wraps the .ics file in RDF via the fromIcal.py converter (courtesy of DanConnolly and the W3C) as deployed at http://torrez.us/ics2rdf/ .

4. Clicking the refresh link in the Shared Interests section of the righthand panel performs a query for all shared foaf:interests of the currently selected people.

• Convention. Amidst some confusion over the intended relationship of foaf:interest and foaf:topic, the demo chose (well, we chose for it) to simply search for shared objects of the foaf:interest predicate. (Of course, the demo could easily be adapted to search for shared foaf:topics of foaf:interests.)

5. Clicking the what can we do together? link runs a SPARQL query that finds, for the currently selected people and shared interests, events that fit the selected interests and are occurring on a date such that all of the selected people would be in the right location to attend. (Note that this query works when a single person is checked, finding events of the selected interest(s) that the selected person can attend in person.)

• Convention. The query attempts to find RDF in the Vcalendar vocabulary at the URI for each shared interest. The demo special-cases URIs to http://www.upcoming.org Upcoming.org]'s RSS syndication feeds (example of feed for upcoming technology events) as a source for event data, by wrapping that RSS in this XSL transform and using the W3C XSLT service to produce RDF. The demo should work with non-upcoming.org URIs for foaf:interests, as long as the URIs resolve to RDF containing calendar events matching that interest. (However, see the further caveat about location matching below.)

• Convention. This query performs a limited version of the PathCross problem. Location matching is currently done purely by string matching: it compares the object of an ical:x-calconnect-location from the interest-events (upcoming.org) data with the object of ical:location from people's calendar data. This is clearly suboptimal, and we'd much prefer to map textual locations into geospatial coordinates and embed a simple distance metric for 'nearby' inside the SPARQL query.

• Limitation. The SPARQL queries do not currently make use of any knowledge about a person's default location (i.e. where am I when I'm not somewhere else?). As such, it will only find events that overlap existing events on the selected people's calendars.

FAQ

1. Failed to get privilege UniversalBrowserRead to open ...

• Firefox security won't in general let a script from a given DNS domain (like www.thefigtrees.net) read web data from a different domain. To change this,
  1. Type into the main browser URI bar "about:config" and hit return to get to the config page.
  2. Scroll down to the line which says signed.applets.codebase_principal_support ... user set ... boolean .. false and double-click it to change it to 'true'.
  3. Go back to the tabulator, and try again. When the browser asks you whether to allow the script to access arbitrary web pages, agree. You probably want to check the "remember the answer this question" box.
  Note that this is reducing the security of your browser. You end up allowing any web page on the site to read data from the web, which could include data from inside your firewall. (Alternative method: Quit Firefox and then find your prefs.js file and add to the bottom of it the line user_pref("signed.applets.codebase_principal_support", true);