From W3C Wiki
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.
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:Person`s 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:interest`s 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:topic`s of `foaf:interest`s.)
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  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:interest`s, 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.
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,
- Type into the main browser URI bar "about:config" and hit return to get to the config page.
- 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'.
- 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);