SPARQL Calendar Demo: Following the Breadcrumbs

This is the second in a series of entries about the SPARQL calendar demo. If you haven't already, you can read the previous entry.

The calendar demo assumes a paradigm whereby the larger the RDF dataset being queried, the more questions can be asked and the more complete the answers are likely to be. New graphs can be added to the dataset in three ways:

  1. The Add button in the top right
  2. The discover more people link
  3. The SPARQL query that populates the People panel

While the first of these three actions grows the dataset directly (the URI is added as a default graph), the second two are examples of simple breadcrumbs protocols. From the tabulator 'about' page:

A breadcrumbs protocol is convention by which information is left to allow another to follow. When the information provider follows the convention on the breadcrumbs to leave, and an information seeker follows the convention on what links to follow, then the protocol that the seeker will be able to solve certain sorts of problem.
In fact, the discover more people link uses exactly the FOAF-link breadcrumbs-protocol example given in the tabulator 'about' page; for all triples p rdfs:seeAlso u, if p has rdf:type foaf:Person then we add u as a default graph in our dataset.

The other breadcrumbs protocol used was developed for this demo and is invoked as part of the SPARQL query that populates the People panel in the righthand column of the demo. In the absence of any widely-accepted manner of associating FOAF data with calendar data, we adopted this protocol as a convention for locating calendars; for all triples p rdfs:seeAlso u, if p has rdf:type foaf:Person and u has rdf:type <>, then we add u as a named graph in our dataset for future queries involving calendars.

In future entries, I'll examine this and the other SPARQL queries in the calendar demo in detail. I'll also look in more detail at this convention, its drawbacks, and possible alternatives. For now, the first lesson that we learned creating this demo was a simple one: finding more data → finding more answers.