Skical in DAML+oil Libby Miller Greg Fitzpatrick Abstract DAML+oil is a language for the precise description of ontologies, building upon RDF and XML Schema. It enables you to describe objects (for example events, people, documents) and their relationships unambiguously. It also uses references to XML Schema datatypes to describe integers, dates and other datatypes. The iCalendar mime-directory standard is a format for describing events, todo lists and journals, including associated date-formats, timezones, and alarms. It is used in most major desktop and PDA Calendaring and Scheduling applications. Skical is an extension to iCalendar which describes 'timespending', the domain of information significant to the interaction of people and resources. The characteristics of DAML+oil are capable of describing aspects of SkiCal objects such as price, age restrictions, start and end dates and times with precision and flexibility. SkiCal makes for a practical and useful potential application of DAML+oil. In our presentation we describe DAML+oil briefly, and show how it can be useful, with particular emphasis on SkiCal. -- DAML+oil DAML+oil is a langauge describing certain constraints you can impose on a graph structure to describe - class heirarchies and relationships (e.g. subclass, same class as, union of, disjoint with, intersection of, untion of, complement of, one of) rdfs:subClassOf, daml:disjointWith, daml:sameClassAs, boolean combinations of class expressions: daml:intersectionOf, daml:unionOf, daml:complementOf Enumerations: daml:oneOf - property heirarchies and relationships rdfs:subPropertyOf daml:samePropertyAs/equivalentTo daml:inverseOf daml:TransitiveProperty - the cardinality of properties (e.g min and max cardinality, cardinality, unique and unambigious property) daml:cardinality, daml:maxCardinality, daml:minCardinality daml:UniqueProperty,daml:UnambigousProperty daml:cardinalityQ, daml:maxCardinalityQ, daml:minCardinalityQ - restrictions on which property can be used where (range, domain, to class, has class ) daml:toClass, daml:hasValue, daml:hasClass rdfs:domain rdfs:range - which datatype objects can go in which position. daml:ObjectProperty daml:DatatypeProperty - instances daml:sameIndividualAs daml:differentIndividualFrom rdf:value (for datatypes) It is based on and uses the RDF model and syntax, and extends the RDF Schema. [ref] A major difference between XML Schema and DAML+oil (which may appear to have overlapping functionality) is that an XML Schema defines a class of XML documents by describing syntactic constraints on those documents, while DAML (like RDFS) is data-orientated, describing constraints on objects, not on documents. DAML+oil (and RDFS) are therefore particularly useful for describing relationships between objects which described over several different documents, including relationships between schemas or ontologies. Skical and iCalendar The iCalendar mime-directory standard is a format for describing events, todo lists and journals, including associated date-formats, timezones, and alarms. It is used in most major desktop and PDA Calendaring and Scheduling applications. Here is an example event described in iCalendar, taken from RFC 2445 [ref] BEGIN:VCALENDAR VERSION:2.0 PRODID:-//hacksw/handcal//NONSGML v1.0//EN BEGIN:VEVENT DTSTART:19970714T170000Z DTEND:19970715T035959Z SUMMARY:Bastille Day Party END:VEVENT END:VCALENDAR Skical is an extension to iCalendar which describes 'timespending', the domain of information significant to the interaction of people and resources. The core technology of SkiCal is the WHA-machine; the structuring of information based on the 6 common interrogatives; WHAT, WHEN, WHERE, WHOW, WHY, and WHO. here is a SkiCal event taken from Skical internet draft [ref] (shortened) BEGIN:VCALENDAR VERSION:2.0 SKICALVER:1.0 PRODID:-//HandGenerated/SkiCal//NONSGML v1.0//EN BEGIN:VEVENT SKUID:kj08988b@nationalchamberorch.org CATEGORIES:music,concert,classical,symphony SUMMARY:Handel's "Messiah" featuring the National Chamber Orchestra TITLE:Messiah DTSTART:19991217T200000 DTEND:19991217T220000 VENUE:Indoors PERSONS;SKiROLE="conductor":Takao Kanayama PERSONS;SKiROLE="orchestra":National Symphony Orchestra PERSONS;SKiROLE="creator":G.F.Handel PRICE;PRXITEM="SFT:Far side";CURRENCY=USD:17 END:VEVENT END:VCALENDAR Both Skical and iCalendar are designed for the machine interchange of event data, including storage and scheduling applications. ICalendar and Skical are both modelled using objects and properties (or entities and relationships). They are not written in XML, but as documents with certain syntactic structure, defined as BNFs. Ordering is not important. There are some cardinality constraints, and in some places, implicit hierarchies. Both iCalendar and SkiCal are good candidates to mark up in RDF, for several reasons. The most important of these is the usefulness of being able to combine event information with other kinds of information, for example about people, documents, webpages, geographical locations. ICalendar has its own notion of things that can sometimes be people - calendar users; SkiCal takes this further by using an explicit Persons property, and enables you to talk about the roles the person might take. Either of these would be useful when combined with a Vcard [ref] or 'friend-of-a-friend' [ref] vocabulary to provide more contact information for the person who might be an organiser of a meeting or a tour guide for a walking tour of Ghostly London. Similarly, being able to connect a well-known vocabulary such as Dublin Core [ref] to event data allows the organiser of a meeting to specify reading material for a meeting, for example. @@ - entity-relationship-based modelling - non-ordered elements @@ Many of these connections to other vocabularies can be described by encoding iCalendar and SkiCal data in RDF using RDFS to describe event objects and their relationships to other objects and vocabularies. DAML+oil can be used to describe these connections with more flexibility and also more precision, for example by sppecifying how many of a certain property may be used with a particular type of object, or by creating constraints on the type of object linked to by a particular property from a certain object. @@ examples here Datatypes are very important for indexing and querying, espcially with respect to dates and times. RDF does not at the time of writing provide a model or syntax for datatyping, whereas DAML+oil can be used with XML Schema datatypes. @@ and potentially for DAML too, because - cardinality constraints - datatypes ...? @@ Practical uses of DAML+oil in SkiCal and iCalendar This section describes some useful aspects of DAML+oil with examples drawn from the iCalendar and SkiCal draft DAML+oil ontologies [ref]. SkiCal and iCalendar are lengthy and complex and so here we pick out three of the more interesting and functional uses of DAML+oil for these calendar ontologies. 1. Assigning identifiers to objects In RDF, objects have names and types, and where the names are global, they represent unique identifiers for the objects. Where they are not global, it is often helpful to be able to say, that if an object has a SKUID property, then that property and value together uniquely identify the object. This assigns an identifier to an object which does not already have one, or which does not naturally fall into the category of things that have one, for example people. DAML+oil has a useful way of saying this. If we state that Then this means that two objects with the same value of a SKUID property are in fact the same object. For example: kj08988b@nationalchamberorch.org Handel's "Messiah" featuring the National Chamber Orchestra kj08988b@nationalchamberorch.org The first perfomance of Handel's "Messiah" by the National Chamber Orchestra for 20 years. kj08988b@nationalchamberorch.org 19991217T200000 all these properties refer to the same VEVENT object. A nice example of this is for people, as described in [ref danbri]. People do not have identifiers like webpages do, but they do have personal email boxes, which at any given time are in the ownership of one person. Email boxes also have the advantage that they are faily well-known strings. If we designate CAL-ADDRESS in iCalendar as a daml:UnambiguousProperty which points to an email address, then we can say if we find the following information: Libby Miller Elizabeth Miller We can tell that the person with email address libby.miller@bristol.ac.uk has two names, Libby Miller and Elizabeth Miller. daml:UnambiguousProperty is a shorthand way of expressing @@a cardinality restriction on the property. It is much like @@ construct in topic maps, which allows for aggregation on topics. This is useful because - where there is no identifier, this creates a unique key for the object. Often it doesn't make sense to assign an event a uri - a modellign error - but a uniqueproperty can be used a surrogate. - It can be used as a key for the database. This means that the database can be indexed, and queries can be ordered to take advantage of this. @@Cardinality in general is useful for constructing queries. A query can be one of two things: it can tell you where an object or groups of objects has all the properties you request; or it can say that in the database there are certain incomplete objects. where you know cardinality is at least one, you can rule out the incomplete objects to start with... @@ 2. Combining namespaces RDF Schema allows you to combine objects from different namespaces using the sublassOf and subpropertyOf constraints: and also domain and range constraints on properties: @@example?@@ DAML has a number of useful ontologies that allow you to link classes and properties together directly, by saying that they are different sames for the same thing. daml:samePropertyAs/equivalentTo, daml:inverseOf and daml:sameClassAs Are useful for creating links between existing ontologies or schemas without rewriting all the instance data. @@examples here@@ DAML also allows you to express domain, range and subclass and subproperty relationships with more subtlety and in more detail. For example you could say more about the sort of calendar users you are expecting, which might affect the sorts of trasactions you expact as a scheduling program: every calendar user is a person or a robot Another example: instead of saying that the range of a property COMPONENT must _always_ have value CALCOMPONENT, we can state this restriction just for a particular class of objects, e.g. for VCALENDAR objects: A container for calendar components - in this case also adding the restriction that there be at least one of the property COMPONENT. This restiction to a local range means that we can reuse COMPONENT elsewhere with different restrictions: if we liked we could create an ical:COMPONENT for CALCOMPONENTS like VEVENTS themselves, perhaps refering to subevents of a main containing event. Other examples are daml:disjointWith, daml:sameClassAs; boolean combinations of class expressions: daml:intersectionOf, daml:unionOf, daml:complementOf. Enumerations: daml:oneOf is useful because it allow you to restrcit the range (for example) of a property to one of a group of different classes. In general however, the level of understanding and detail that needs to be put into the creation of very detailed relationships between and within schemas and ontologies is too great for many people to bother with, except for very straightforward relation such as sameClassAs, samePropertyAs, inverseOf. (and all of these imply greater exactness of understanding of other schemas than can reasonably be expected). 3. Using XML Schema datatypes with RDF Calendaring and scheduling applications need to be able to do operations on dates and times, such as: 'find all the events that the calendar user libby is attending within the next week' 'find all the events that calendar users greg and dan are both attending between June 21st 2002 and August 16th 2003' 'find every time period that damian is free between 8.30am and 7.00pm GMT today' To display calendar information or schedule events, applications need to be able to makes these types of queries of a source of data, and that requires knowing that certain objects are the sorts of things that one can perform a 'greater than', 'less than' or 'between' operation on. Datayping can also enable or speed indexing in databases (for example in several relational databases, datatyping is the only way that queries about dates can be made). RDF does not at the time of writing have a completed model, syntax or schema constructs for expressing datatypes of any kind. DAML+oil has its own methods of using datatypes. It has certain syntactic structures to point to XML Schema dataypes, both at the schema and the instance level. For example, defining iCalendar in DAML+oil, one could say: In which case sample instance data could look like this: 2002-03-15T15:00Z and a DAML+oil processor could determine using the schema that the string 2002-03-15T15:00Z represented a XML Schema datatype, and index it accordingly. Unfortunately the syntactic description of a date-time in icalendar is not an identical subset of iso 8601, and so translating iCalendar correctly to DAML+oil would involve creating a new datatype (without - or :). This can be achieved by creating an XML Schema file with the correct restrictions and pointing to the datatypes in that. One other difficulty was with the use of timezones in iCalendar - modelling TZIDs requires having an object in daml-space rather than pointing at datatypes space (they are disjoint in daml). In some cases this distinction is difficult to draw clearly. For example, should you say that ical:DESCRIPTION is a daml:DatatypeProperty with a xsd:String value or ical:DESCRIPTION is a daml:ObjectProperty with a rdf:Literal value similarly, is it: ical:URI is a daml:DatatypeProperty value xsd:anyURI or ical:URI is a daml:ObjectProperty value rdf:Resource However, in many cases XML Schema datatypes are a useful and also extensible mechanism for datatypes. For example in SkiCal information about age restrictions are currently contained described in instructured text, but we could define an extension to SkiCal specifically for movies and define our own XML Schema datatypes for the categoies of agegroup used: (example adapted from the DAML+oil walkthrough [ref]) and then point at this in the skical extension like this: (schema) (instance data) Texas Chain Saw Massacre, The 18 Problems with DAML+oil The authors undertook the process of creating a DAML+oil schema for iCalendar and SkiCal, and found the process very difficult and slow. Part of this was because of the difficulty of translating between schema specification laguages, but a major problem was with the awkward syntax and limited expressivity of the DAML+oil language. A short position paper by Pat Hayes [ref] explains the source of the latter difficulty very clearly. The syntactic difiiculties are due to the difficulty of expressing complex constraints within the binary RDF model. DAML+oil has several useful aspects for describing and constraining calendar and other data. We found the cardinality constraints and the datatypes most useful in this case. References Internet Calendaring and Scheduling Core Object Specification (iCalendar) Network Working Group November 1998 Request for Comments: 2445 Category: Standards Track F. Dawson, D. Stenerson http://www.imc.org/rfc2445 SkiCal Internet Draft Network Working Group Internet-Draft Expires: July 8, 2002 G. FitzPatrick, P. LannerĂ, N. Hjelm http://www.ietf.org/internet-drafts/draft-many-ical-ski-05.txt Annotated DAML+OIL (March 2001) Ontology Markup (DAML+oil walkthu) Frank van Harmelen, Peter F. Patel-Schneider and Ian Horrocks, editors (also Lynn Andrea Stein, Dan Connolly, and Deborah McGuinness, editors of previous versions) http://www.daml.org/2001/03/daml+oil-walkthru.html Reference description of the DAML+OIL (March 2001) ontology markup language Frank van Harmelen, Peter F. Patel-Schneider and Ian Horrocks, editors. Contributors: Tim Berners-Lee, Dan Brickley, Dan Connolly, Mike Dean, Stefan Decker, Pat Hayes, Jeff Heflin, Jim Hendler, Ora Lassila, Deb McGuinness, Lynn Andrea Stein, ... http://www.daml.org/2001/03/reference.html Notes on defining SkiCal in DAML+oil (will be cleaned up) 2002-03-22 Libby Miller http://swordfish.rdfweb.org/people/libby/rdfweb/skical/skical-daml-diary.txt Draft iCalendar and SkiCal DAML+oil schemas (unfinished) 2002-03-22 Libby Miller http://swordfish.rdfweb.org/people/libby/rdfweb/skical/ical-daml.daml XML Schema Part 2: Datatypes W3C Recommendation 02 May 2001 Paul V. Biron, Ashok Malhotra http://www.w3.org/TR/xmlschema-2/ XML Schema Part 0: Primer W3C Recommendation, 2 May 2001 David C. Fallside (editor) http://www.w3.org/TR/xmlschema-0/ Draft Hybrid RDF Calendar Schema Michael Arick and Libby Miller 2001-06-18 http://ilrt.org/discovery/2001/06/schemas/ical-full/hybrid.rdf RDF Schema Specification 1.0 Dan Brickley and R.V. Guha W3C Candidate Recommendation 27 March 2000 http://www.w3.org/TR/rdf-schema RDF Model and Syntax Specification Ora Lassila and Ralph R. Swick W3C Recommendation 22 February 1999 http://www.w3.org/TR/REC-rdf-syntax