Calendar Mashup in TopBraid Composer

Mashups are applications that combine content from multiple sources into a single view. For example, if one web page lists the dates and addresses of certain conferences and another web service knows how to convert addresses into geographical coordinates, then it would be helpful to extract both pieces of information into an integrated experience to help with travel arrangements. The open architecture of Semantic Web languages like RDF Schema and OWL make it relatively easy to bring together information from various sources. Once the data structures are brought together and aligned, they can be displayed and analyzed.

We are incrementally extending our RDF/OWL development tool TopBraid Composer with new forms of visualization. This allows ontology designers and data architects to directly experience what they can actually do with the ontologies. TopBraid already has support for geographical information with its Google Maps interface, but version 1.5 now also introduces a Calendar view.



The Calendar View enables users to visualize xsd:date and xsd:dateTime values from an RDF/OWL model on a month-by-month basis. Users select which properties to show and the system then renders them into their corresponding day boxes. In the following screenshot, the Calendar is shown alongside with the geographical viewer (click for a larger image).



As you can see on these images, some temporal values are displayed to cover multiple days, i.e. they represent a "time span". Well, but there is no standard way to formalize a "time span" in RDF, so you may wonder how does the system actually know that some properties shall be interpreted as start and end points of a time interval? The flexibility of RDF Schema enables a quite elegant solution to this problem. The Calendar is connected to a small Calendar ontology which defines two properties calendar:startTime and calendar:endTime. If your domain has a pair of properties travel:departureDate and travel:returnDate then you just need to make these properties subproperties of the calendar properties, and run the classifier to tell the system that all departureDate values shall be interpreted as startTime and all associated returnDates shall become endTimes as well. Instead of having to change the code or configuration of the Calendar itself, we just change the model to drive the existing viewer.