Skical-daml notes libby.miller@bristol.ac.uk 2002-03-07 The idea here is to keep a diary of my attempts to express skical in terms of daml. 2002-03-07 looked for current skical draft: http://www.ietf.org/internet-drafts/draft-many-ical-ski-04.txt plan: do a skim, and then look at the list of daml properties to see what if anything would be useful for skical. [[ SkiCal is based on and extends the iCalendar format as defined by RFC-2445, Internet Calendaring and Scheduling Core Object Specification [3] (iCalendar). ]] there is already an RDF version of icalendar that I helped to write: http://www.ilrt.bris.ac.uk/discovery/2001/06/schemas/ical-full/hybrid.rdf * changed my mind, read daml first http://www.daml.org/ http://www.daml.org/roadmap.html [[ software developer XML enthusiast logician WWW standards junkie program manager Semantic Web researcher military user reporter ]] hm...schema writer? http://www.daml.org/roadmap.html#researcher about http://www.daml.org/about.html [[ The use of XML to provide metadata markup, such as Algol, makes the meaning of the work unambiguous. However, XML has a limited capability to describe the relationships (schemas or ontologies) with respect to objects. The use of ontologies provides a very powerful way to describe objects and their relationships to other objects. The DAML language is being developed as an extension to XML and the Resource Description Framework (RDF). The latest release of the language (DAML+OIL) provides a rich set of constructs with which to create ontologies and to markup information so that it is machine readable and understandable. ]] -- looks like it is suitable for skical some ontologies http://www.daml.org/ontologies/ontologies.html by keyword http://www.daml.org/ontologies/keyword.html "time" http://www.kestrel.edu/DAML/2000/12/TIME.daml http://www.daml.ri.cmu.edu/ont/homework/atlas-date.daml http://www.kestrel.edu/DAML/2000/12/TIME.daml http://opencyc.sourceforge.net/daml/cyc.daml http://www.cyc.com/cyc-2-1/cyc-vocab.daml "date" http://www.daml.ri.cmu.edu/ont/homework/atlas-date.daml "people" http://www.cs.yale.edu/~dvm/daml/pddlonto.daml http://ontolingua.stanford.edu/doc/chimaera/ontologies/world-fact-book.daml http://www.cs.umd.edu/projects/plus/DAML/onts/personal1.0.daml http://www.daml.org/2001/12/factbook/factbook-ont http://www.engr.sc.edu/research/cit/projects/DAML.html http://www.ksl.stanford.edu/projects/DAML/ksl-daml-desc.daml "person" http://mnemosyne.umd.edu/~aelkiss/daml/serial1.2.daml http://orlando.drc.com/daml/ontology/Person/current/ http://ubot.lockheedmartin.com/ubot/2001/08/baby-shoe/shoeproj-ont.daml http://www.cs.umd.edu/projects/plus/DAML/onts/personal1.0.daml http://www.daml.ri.cmu.edu/ont/homework/atlas-cmu.daml http://www.ksl.stanford.edu/projects/DAML/ksl-daml-instances.daml http://www.davincinetbook.com:8080/daml/rdf/personal-info.daml http://www.engr.sc.edu/research/cit/projects/DAML.html http://www.cs.umd.edu/projects/plus/DAML/onts/personal1.0.daml "event" http://daml.umbc.edu/ontologies/talk-ont.daml lots and lots that are potentially useful. might be useful to see modelling styles. but we want to convert and existing ontology, so return to more explanations of daml walkthough http://www.daml.org/2001/03/daml+oil-walkthru.html [[ Defining Classes Now, we begin our ontology definitions. In order to describe objects, it is useful to define some basic types. This is done by giving a name for a class, which is the subset of the universe which contains all objects of that type. ]] we need to define what are classes in skical we can use datatypes in daml (good for times, other things? ages?) daml can have disjoint classes it can have a heirarchy; a class can have several superclasses, in which case it must satisfy both, unless othwise stated (how?) [[ Defining Properties Next, we define a property. A property -- or binary relation -- connects two items. As with classes, DAML+OIL properties are generally divided into two sorts -- those that relate objects to other objects and those that relate objects to datatype values. ]] so we have to distinguish classes and properties in skical. and we can define domain and range for properties: domain is saying that the property applies to a particular class of objects. range constrains the values of the properties. can have multiple ranges (but not domains?). then to satisfy the contraint, a property and value must satisfy all ranges. domain and range are 'global information about properties' ?? [[ Next, we state that hasFather is a property that is a kind of hasParent property, i.e., x's father is also x's parentsubProperty. ]] ?? but understand this, I think: [[ ]] hasFather is a special kind of hasParent propety, and the difference is that the value must be a male. object->datatypes properties are of a different type in the example: [[ shoesize is a DatatypeProperty whose range is xsd:decimal. shoesize is also a UniqueProperty (can only have one shoesize) ]] uniqueproperty seems to mean that there is at most one shoesize for the object the prop is danging off. and the range - the value - is a decimal. so that means you couldn't have more than one of these props hanging off anything (there's no domain). maybe this is what they mean by global. so I suppose noone could say subproperty shoesize and make it less restrictive, e.g. allow shoe sizes in diffrent countries. maybe this would be a different property... can you subclass something that isn't in your namesapce? (yes). what happens if you don't have the schema or dont understand it and screw up, by subclassng the property (if that can be done) - i.e. what happens to software? .... anyway.... Defining property restrictions you can say that a person must have hasparent person, but I'm finding the syntax hard... [[ ]] there is a class called Person which is a subclass of a thing which must have a thing of class Person at the end of its hasParent property. I think. i.e. if a person has a parent then that parent must be a person. so I see that this is like range, kinda. range constrains the values of the properties. so does this. i'm not totally sure of the diference. Oh, this constrains the values of a property when applied to a certain class. yep: [[ An rdfs:range element has a global scope: any use of the hasFather property for any class must always yield a male. A toClass restriction (as used in the Person class) on the other hand has a local scope: the parent of a person must be person, but the parent of any other class (e.g. the parent of an elephant) need not be a person. ]] and toclass is better apparantly: [[ Note: In general, stating toClass restrictions locally to a class will result in ontologies that are more extendable (and therefore more reusable) then those using rdfs:range and rdfs:domain. The latter two make global assertions that must be obeyed by anyone who will ever want to use the property concerned, applied to any class whatsoever. Because of this, using local Restriction elements is considered much better DAML+OIL style than using global rdfs:domain and rdfs:range. ]] [[ ]] this is person again. so this means that the person must have exactly one father - a subclass of the class of all things with exactly one father. compare to the previous one [[ ]] this hasnt got a 'toclass' part, why not? so this isnt quite like range, which points to a class as well as a property, as it's a restriction on the property, not on a combination of property and class. compare: [[ age is a DatatypeProperty whose range is xsd:decimal. age is also a UniqueProperty (can only have one age) ]] the former says somthing about a restriction on an anonymous class, which limits the number of fathers to 1; the unique property thing means you can have at most one of these properties. so the restriction is a restriction on the class, and uniqueproperty is a restriction on a property. I'm really unclear about the difference. a person can only have one father (restriction on the class Person) so you cant have: Person1 -hasFather-> Jim Person1 -hasFather-> dave uniquepropertymeans that there's only one of that property. so you can't have: Person1 -hasFather-> Jim Person1 -hasFather-> dave ?? why are there 2 ways of saying the same thing? is the seocnd global and the first local? ...maybe... You can also talk about cardinality: [[ 1 ]] so intead of there being exactly one, then there is at least one. makes sense. Does this conflict with [[ shoesize is a DatatypeProperty whose range is xsd:decimal. shoesize is also a UniqueProperty (can only have one shoesize) ]] from before? there we said can only be one (globally); here we are saying there must be at least one (locally, I think). I guess here's no conflict. 1==1 * boy this is hard going those two cardinality things were just different ways of using cardinality constraints; the syntax can be used either way, as you'd expect from RDF. The onproperty thing has special semantics, I can see that, that's why they say it's a 'cliche' - it's daml-processor specific. [[ Besides toClass and cardinality, other restrictions are possible. These are all discussed in the reference document on DAML+OIL. ]] * need to look at http://www.daml.org/2001/03/reference.html, in a bit [[ That's the end of the Person class. ]] * thank god * you can talk about objects within the current docuent using rdf:about="#theirID"; or from another file with a full url. (as with rdf) [[daml:maxCardinality="1"]] == no more than one spouse; ditto minimum. min is assumed 0 unless specified. --- * as an aside, I wonder if there are 2 things going on w daml, one a set of constraints about data structures, which would be useful for defining a database, or defining a query; the other a set of assertions about the world, which might be less useful. so what would you use something like this for? I guess we'll try to find out... --- [[ ]] [[ This states that a Person may have at most one occupation that is a FullTimeOccupation. ]] is this a restriction on the property? compare [[ ]] the above is a restriction on the thing at the end of a hasParent arc for Person hasClassQ==?a restriction on a property that is a subproperty of #FullTimeOccupation? ??dunno, capital F implies that #FullTimeOccupation is a class. so in that case, the diff between this and toclass, is that the value of toClass is compulsory if you have hasOccupation on a Person; hasClassQ is a restriction on the value of hasOccupation which is the cardinality thing, a property constraint that kicks in only in the prescence of a value of type #FullTimeOccupation. so toclass is a restriction on all values at the end of this arc for this type of object; hasClassQ is a restriction on meta-aspects of the property (like cardinality) in the presence of a partcular type at the end of the property arc for this class Person. _if_ it is hasClassQ Person1 - hasOccuaption -> FullTimeOcuupation _then_ there's only one hasOccupation arc whereas toClass says that if we have Person1 - hasParent -> bla1 then bla1 must be of class Person * ok, think I've got that finally. * taking a break. * thinking - this stuff probably fits quite well with skical, which since based on icalendar will have lots of stuff about MUST and should have certain properties. Would be useful for generating html forms for data input maybe. [[ Notations for properties A UniqueProperty is one with cardinality 1 ... Since a UniqueProperty has cardinality 1, each subject uniquely identifies the object (value) of the property (ie. the identity of a person determines their mother). Conversely, an UnambiguousProperty is a property whose object uniquely identifies its subject. (The inverse of any UniqueProperty is always an UnambiguousProperty). ]] s -uniqueP -> o == only one o per s s - unambigousP -> o == only one s per o ??inverse?? s - hasPersonalMbox -> libby.miller@bristol.ac.uk == unambigousP; only one s libby.miller@bristol.ac.uk - personalMboxOf -> o == uniqueP; only one o [[ Notice that UniqueProperty and UnambiguousProperty specify global cardinality restrictions. That is, no matter what class the property is applied to, the cardinality constraints must hold, unlike the cardinality restrictions illustrated above, which are part of a class element, and are only enforced on the property when applied to that class. ]] so you can't specify cardinaity=1 on a property without that indirection. inverse: [[ If x's parent is y, then y is x's child. This is defined using the inverseOf tag. ]] as above, sounds plausible. [[ The hasAncestor and descendent properties are transitive versions of the hasParent and hasChild properties. hasAncestor ]] ??what does this actually mean? ??is it like [[ ]] but global? [[ Note that this only states that hasAncestor is transitive, but not yet that hasAncestor is the transitive version of hasParent (and ditto for hasDescendant and hasChild). DAML+OIL would need additional language constructs to enforce these connections. ]] synonym. I'm not sure what this means though [[ ]] Notations for classes [[ ]] - cars can never be persons - car is a specialization of not-persons ==the same as daml:disjointWith can also say that a list of things are pairwise disjoint: [[ ]] [[ We can also identify a Class with the disjoint union of a set of other classes. In this case, we identify the Class Person with the disjoint union of the Classes Man and Woman. ]] [[ every person is a man or a woman ]] it seems odd that this doesn't follow the subclassof routine from before...its rather like the semantics are like that but the disjuntionof provides a shortcut. ??maybe?? [[ ]] can construct classes out of the intersection of other calsses [[ the intersectionOf construction makes the named class exactly equal to the result of the intersection ]] can be used to enforce necessary and sufficient ** sounds useful [[ ]] so a marriedPerson is an intersection of Person and an anon class with a single property of hasSpouse, i.e. a subclass of the intersection of the class Person, and an anon class which is the class of all things with exactly one spouse. [[ Just as for properties, a mechanism exists for declaring synonyms for classes: ]] - looks ok... [[ Using User-defined Datatypes ]] basically you create an XML schema for the new datatype, and just point to that. [[ Defining individuals We can also define individual objects in a class, e.g., Adam, a person of age 13 and shoesize 9.5: ]] [[ Adam Adam is a person. ]] - same as RDF, with a partciaulr syntax for dataatypes [[ one of ]] defining a class by specifing a collection of options that a class can take [[ ]] [[ Finally, TallThing is exactly the class of things whose hasHeight has the value tall: ]] [[ besides being necessary, this condition is also sufficient for being a TallThing. ]] [[ Consider what would have happened if we had used subClassOf instead of sameClassAs. This would have resulted in a necessary but not sufficient condition for the definition of the class TallThing. Thus, a necessary-only and a necessary-and-sufficient class definition now only differ simply in their outermost element: either a subClassOf or a sameClassAs as element, respectively. ]] * end ------------------------------ * now looking at http://www.ietf.org/internet-drafts/draft-many-ical-ski-04.txt [[ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. ]] missing ref to rfc 2445....skical depends on it [[ SkiCal objects are comprised of either VEVENT components with the addition of new properties and property parameters, or the SkiCal specific VOPTIME calendar component described in this memo. ]] because ical is so large, looked for more help, using Michael Arick's iCalendar in UML: http://www.cse.ucsc.edu/~marick/iCalendarUML.html this is a very neat summary: the text part enabled me to see that the icalendar model was a basic entity-rel model, and therefore fitted RDF well. The uml diags enabled me to see which parts of the spec were primarily used by SkiCal. [[ SkiCal objects are comprised of either VEVENT components with the addition of new properties and property parameters, or the SkiCal specific VOPTIME calendar component described in this memo. ]] - concentrate on the VEVENT parts of ical, and dont worry too much about the rest. --- vevent and ical: looking at http://www.cse.ucsc.edu/~marick/iCalendarUML.html and http://www.imc.org/rfc2445 ical distinguishes between 'property parameters' (attributes), properties, and calendar components. RDF has to call property parameters and calendar components resources, and properties rdf properties. further distinctions can be made by subclassing and subpropertying the rdf props and resources. properties have optional and required attributes. --- [[ 3. SkiCal specific Property Parameters The following SkiCal property parameters are in addition to those defined by RFC-2445 Section 4.2 [3] and may be used as specified for the individual properties of this memo. ]] (namely) [[ 4.2 Property Parameters .........................................17 4.2.1 Alternate Text Representation ............................18 4.2.2 Common Name ..............................................19 4.2.3 Calendar User Type .......................................20 4.2.4 Delegators ...............................................20 4.2.5 Delegatees ...............................................21 4.2.6 Directory Entry Reference ................................21 4.2.7 Inline Encoding ..........................................22 4.2.8 Format Type ..............................................23 4.2.9 Free/Busy Time Type ......................................23 4.2.10 Language ................................................24 4.2.11 Group or List Membership ................................25 4.2.12 Participation Status ....................................25 4.2.13 Recurrence Identifier Range .............................27 4.2.14 Alarm Trigger Relationship ..............................27 4.2.15 Relationship Type .......................................28 4.2.16 Participation Role ......................................29 4.2.17 RSVP Expectation ........................................29 4.2.18 Sent By .................................................30 4.2.19 Time Zone Identifier ....................................30 4.2.20 Value Data Types ........................................32 ]] [[ 4. SkiCal Specific Property Value Data Types The following SkiCal property value datatypes are in addition to those defined by RFC-2445 Section 4.2 [3] ]] [[ 4.3 SkiCal specific Component Properties The class of SkiCal objects is a superset of the class of iCalendar objects. Therefore any component property, which MAY appear in a VEVENT iCalendar component, is also allowed in a SkiCal object. In addition, the following component properties are defined in this memo. ]] [[ 4.1 The OpeningTimes Set . . . . . . . . . . . . . . . . . . 15 4.1.1 Terms used in the OPTIMESET data value declaration . . 15 4.1.1.1 Differences between ISO8601 and RFC2445 . . . . . . . . 18 4.1.1.2 Optimelist DTD . . . . . . . . . . . . . . . . . . . . . 18 4.1.2 Term of the OPTIMESET . . . . . . . . . . . . . . . . . 20 4.1.3 Seasons of the OPTIMESET . . . . . . . . . . . . . . . . 23 4.1.4 Days of the OPTIMESET . . . . . . . . . . . . . . . . . 25 4.1.5 Hours of the OPTIMESET . . . . . . . . . . . . . . . . . 27 4.1.6 Minutes of the OPTIMESET . . . . . . . . . . . . . . . . 27 4.1.7 Seconds of the OPTIMESET . . . . . . . . . . . . . . . . 28 4.2 SkiCal specific Calendar Component . . . . . . . . . . . 29 4.2.1 The OpTime calendar component . . . . . . . . . . . . . 30 4.3 SkiCal specific Component Properties . . . . . . . . . . 33 4.3.1 WHAT properties . . . . . . . . . . . . . . . . . . . . 34 4.3.1.1 Title . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.3.1.2 Persons . . . . . . . . . . . . . . . . . . . . . . . . 36 4.3.1.3 Thinks . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.3.1.4 Things . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.3.1.5 Actions . . . . . . . . . . . . . . . . . . . . . . . . 39 4.3.1.6 Part relationship to another SkiSource . . . . . . . . . 41 4.3.1.7 Language used at the SkiSource . . . . . . . . . . . . . 42 4.3.1.8 Orientation . . . . . . . . . . . . . . . . . . . . . . 43 4.3.1.9 What URL . . . . . . . . . . . . . . . . . . . . . . . . 44 4.3.1.10 SkiSource Unique Identifier . . . . . . . . . . . . . . 45 4.3.2 WHEN properties . . . . . . . . . . . . . . . . . . . . 46 4.3.2.1 Date-time open . . . . . . . . . . . . . . . . . . . . . 47 4.3.3 WHERE properties . . . . . . . . . . . . . . . . . . . . 48 4.3.3.1 Venue . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.3.3.2 Directions . . . . . . . . . . . . . . . . . . . . . . . 49 4.3.3.3 Place name . . . . . . . . . . . . . . . . . . . . . . . 51 4.3.4 WHOW (HOW) properties . . . . . . . . . . . . . . . . . 52 4.3.4.1 Requirements . . . . . . . . . . . . . . . . . . . . . . 53 4.3.4.2 Recommendations . . . . . . . . . . . . . . . . . . . . 54 4.3.4.3 Prohibited . . . . . . . . . . . . . . . . . . . . . . . 55 4.3.4.4 Price . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.3.4.5 Bookings . . . . . . . . . . . . . . . . . . . . . . . . 58 4.3.4.6 Special access facilities . . . . . . . . . . . . . . . 59 4.3.4.7 Accepted method of payment . . . . . . . . . . . . . . . 60 4.3.5 WHY properties . . . . . . . . . . . . . . . . . . . . . 61 4.3.5.1 Promotion . . . . . . . . . . . . . . . . . . . . . . . 62 4.3.6 WHO properties . . . . . . . . . . . . . . . . . . . . . 63 4.3.6.1 Control . . . . . . . . . . . . . . . . . . . . . . . . 64 4.3.7 MANAGEMENT properties . . . . . . . . . . . . . . . . . 65 4.3.7.1 Publisher . . . . . . . . . . . . . . . . . . . . . . . 66 4.3.7.2 SkiCal Version . . . . . . . . . . . . . . . . . . . . . 67 4.3.7.3 Namespace . . . . . . . . . . . . . . . . . . . . . . . 68 4.3.7.4 Open Times . . . . . . . . . . . . . . . . . . . . . . . 69 ]] ical component properties: [[ 4.8 Component Properties ........................................77 4.8.1 Descriptive Component Properties .........................77 4.8.1.1 Attachment ...........................................77 4.8.1.2 Categories ...........................................78 4.8.1.3 Classification .......................................79 4.8.1.4 Comment ..............................................80 4.8.1.5 Description ..........................................81 4.8.1.6 Geographic Position ..................................82 4.8.1.7 Location .............................................84 4.8.1.8 Percent Complete .....................................85 4.8.1.9 Priority .............................................85 4.8.1.10 Resources ...........................................87 4.8.1.11 Status ..............................................88 4.8.1.12 Summary .............................................89 4.8.2 Date and Time Component Properties .......................90 4.8.2.1 Date/Time Completed ..................................90 4.8.2.2 Date/Time End ........................................91 4.8.2.3 Date/Time Due ........................................92 4.8.2.4 Date/Time Start ......................................93 4.8.2.5 Duration .............................................94 4.8.2.6 Free/Busy Time .......................................95 4.8.2.7 Time Transparency ....................................96 4.8.3 Time Zone Component Properties ...........................97 4.8.3.1 Time Zone Identifier .................................97 4.8.3.2 Time Zone Name .......................................98 4.8.3.3 Time Zone Offset From ................................99 4.8.3.4 Time Zone Offset To .................................100 4.8.3.5 Time Zone URL .......................................101 4.8.4 Relationship Component Properties .......................102 4.8.4.1 Attendee ............................................102 4.8.4.2 Contact .............................................104 4.8.4.3 Organizer ...........................................106 4.8.4.4 Recurrence ID .......................................107 4.8.4.5 Related To ..........................................109 4.8.4.6 Uniform Resource Locator ............................110 4.8.4.7 Unique Identifier ...................................111 4.8.5 Recurrence Component Properties .........................112 4.8.5.1 Exception Date/Times ................................112 4.8.5.2 Exception Rule ......................................114 4.8.5.3 Recurrence Date/Times ...............................115 4.8.5.4 Recurrence Rule .....................................117 4.8.6 Alarm Component Properties ..............................126 4.8.6.1 Action ..............................................126 4.8.6.2 Repeat Count ........................................126 4.8.6.3 Trigger .............................................127 ]] -- because this is so many, I'm going to just pick some of the more useful ones from ical, and try to work out a principled way of converting between ical and daml. then I will try and work out how to do skical itself. so, from ical: property params I will use are:?? 4.2 Property Parameters .........................................17 4.2.2 Common Name ..............................................19 4.2.3 Calendar User Type .......................................20 4.2.20 Value Data Types ........................................32 component props I will use are: 4.8 Component Properties ........................................77 4.8.1 Descriptive Component Properties .........................77 4.8.1.5 Description ..........................................81 4.8.2 Date and Time Component Properties .......................90 4.8.2.2 Date/Time End ........................................91 4.8.2.4 Date/Time Start ......................................93 4.8.2.5 Duration .............................................94 4.8.3 Time Zone Component Properties ...........................97 4.8.3.1 Time Zone Identifier .................................97 4.8.4 Relationship Component Properties .......................102 4.8.4.1 Attendee ............................................102 4.8.4.6 Uniform Resource Locator ............................110 a note on recurrance properties: 4.8.5 Recurrence Component Properties .........................112 4.8.5.1 Exception Date/Times ................................112 4.8.5.2 Exception Rule ......................................114 4.8.5.3 Recurrence Date/Times ...............................115 4.8.5.4 Recurrence Rule .....................................117 Calendar components I will use: 4.4 iCalendar Object ............................................50 4.5 Property ....................................................51 4.6 Calendar Components .........................................51 4.6.1 Event Component ..........................................52 == somewhat arbitrary, knowledge from previous RDF ical work. -- then the skical stuff Calendar components I will use: 4.4 iCalendar Object ............................................50 4.5 Property ....................................................51 4.6 Calendar Components .........................................51 4.6.1 Event Component ..........................................52 [[ 4.4 iCalendar Object The Calendaring and Scheduling Core Object is a collection of calendaring and scheduling information. Typically, this information will consist of a single iCalendar object. However, multiple iCalendar objects can be sequentially grouped together. The first line and last line of the iCalendar object MUST contain a pair of iCalendar object delimiter strings. The syntax for an iCalendar object is as follows: ... ]] this information about must is syntactic. basically this is an RDF:Class of type rdf:VCALENDAR. in DAML we have VCALENDAR This object is the grouping mechanism for iCalendar components. we don't know anything about its relationship to other classes, so this is all we can say. -- icalendar has its own notion of property, which we define here in terms of daml. Daml has two types of property, one that relates object to object, and one that related object to datatypes. (daml:ObjectProperty and daml:DatatypeProperty) icalendar properties are [[ A property is the definition of an individual attribute describing a calendar or a calendar component. A property takes the form defined by the "contentline" notation defined in section 4.1.1. ]] this is more general than a daml property. it's more like an rdf:property, which points to either type. To define it in daml, * looking in http://www.daml.org/2001/03/reference.html#Property in case this superclass of both has already been defined in the normative daml document * looking up objectproperty and datatypeproperty and find they are both subclasses of rdf:property. So I have 2 choices: I could say something like ical:property is the disjoint union of objectproperty and datatypeproperty. i.e. every ical:property is either an object property or a datatypes property every ical property is a daml object property or a daml:datatype property however, this is very daml specific. I might just be as well off with rdf: Property ical properties are identical to rdfs property at the moment. ??case-sensitivity? -- Calendar components [[ The body of the iCalendar object consists of a sequence of calendar properties and one or more calendar components. The calendar properties are attributes that apply to the calendar as a whole. The calendar components are collections of properties that express a particular calendar semantic. For example, the calendar component can specify an event, a to-do, a journal entry, time zone information, or free/busy time information, or an alarm. ]] ...but here we are interested only in the vevent type of calendar component. - first we look at the calendar properties. [[ An iCalendar object MUST include the "PRODID" and "VERSION" calendar properties. In addition, it MUST include at least one calendar component. ]] A container for calendar components We want to say: icalendar objects have at least one prodid and version cal properties, and at least one calendar component. We can do this in daml: A container for calendar components 1 1 1 - I'm not sure about the last. I've assigned a property name and a calendar component class. we also need to say somethign about the relationship between CALCOMPONENT and (eventc / todoc / journalc / freebusyc / / timezonec / iana-comp / x-comp) An iCalendar event - this doesnt give us more information than rdfs. -----end of calendar components from ical ---start of property params property params I will use are:?? 4.2 Property Parameters .........................................17 4.2.2 Common Name ..............................................19 4.2.3 Calendar User Type .......................................20 4.2.20 Value Data Types ........................................32 [[ A property can have attributes associated with it. These "property parameters" contain meta-information about the property or the property value. Property parameters are provided to specify such information as the location of an alternate text representation for a property value, the language of a text property value, the data type of the property value and other attributes. ]] there are more than 20 of these. The icalendar property parameters model does not fit closely with the RDF model. RDF can have properties associated with a property where tht property is described (usually in a schema). But many of ical's property parameters act more like additional properties of the values of a property, rather than the property itself. for example altrepparam = "ALTREP" "=" DQUOTE uri DQUOTE [[ Description: The parameter specifies a URI that points to an alternate representation for a textual property value. A property specifying this parameter MUST also include a value that reflects the default representation of the text value. The individual URI parameter values MUST each be specified in a quoted-string. ]] This says that a textual value for a node can have a property which specifies an alternative textual representation. An example of such a textual node might be a description. REgardless of how text is handled (as a datatype) the alternatice representation can be modelled as a respresntation of the value of the description property, rather than as a constraint on the property. At any rate, you can do this in RDF, and you have to, too. common name is similar 4.2.2 Common Name [[ Purpose: To specify the common name to be associated with the calendar user specified by the property. ]] This has a very specific link to a certain type of object, a calendar user, which we haven't defined yet. "CN" [[ Description: This parameter can be specified on properties with a CAL-ADDRESS value type. The parameter specifies the common name to be associated with the calendar user specified by the property. The parameter value is text. The parameter value can be used for display text to be associated with the calendar address specified by the property. ]] it seems clear that cal-address is an object in this system, although we don't know much about it. To define our CN property, we nede to specify its domain to be the cal-address class, i.e. to say that the thing it points from is a cal-address object. we can do this with RDFS: (we dont know what text is at the momenmt) or in daml with a global domain and range restriction on an objectProperty: (does this tell us any more than rdfs?) (why does daml use ID instead of about?) the global restrictions for range means that the value of any use of CN on any class must be a text object. the global restriction for domain means that any use of CN at all must be on a CAL_ADDRESS object. together, they imply that you cuod only use this property between a cal-address object and a text object. this seems comewhat restrictive: maybe the domain could be other things but the range should be text? But this kind of depends how we define text.... You could also to it in daml with a more restrictive, local domain and range: local domain: !! I can't work out how to do this from the primer or for searching for plausible names for the restriction in http://www.daml.org/2001/03/daml+oil.daml! I want something like onProperty/toClass but from Class or somsuch. you can do it for a local version of range, e.g. for domain? ???? - I don't know. For this I'd suggest stick with RDFS or daml global. --- [[ 4.2.3 Calendar User Type Parameter Name: CUTYPE Purpose: To specify the type of calendar user specified by the property. Format Definition: The property parameter is defined by the following notation: cutypeparam = "CUTYPE" "=" ("INDIVIDUAL" ; An individual / "GROUP" ; A group of individuals / "RESOURCE" ; A physical resource / "ROOM" ; A room resource / "UNKNOWN" ; Otherwise not known / x-name ; Experimental type / iana-token) ; Other IANA registered ; type ; Default is INDIVIDUAL Description: This parameter can be specified on properties with a CAL-ADDRESS value type. The parameter identifies the type of calendar user specified by the property. If not specified on a property that allows this parameter, the default is INDIVIDUAL. ]] so this is like CN, a property of on CAL-ADDRESS 2 things are interesting about CUTYPE: defaults and contrained values. 1. Defaults: [[ Default is INDIVIDUAL ]] can daml+oil do defults? (I know this has come up as something desireable in OWL, but I don't know offhand if daml can. I know that it's hard, so maybe not) ->google search http://google.com/search?q=daml+default&hl=en&start=10&sa=N - didn't find anything promising. 2. constrained values this rings a bell from the daml walkthrough. yes, you can describe a class by an explicitly enumerated set, for example: [[ ]] so I guess we could have: (unsure how to define x name or iana token, which are not strings but definitions of strings...) compare the similar thing that Michael Arick defined in rdf hybrid schema for icalendar: [[ ]] the daml version is an explicit version of the hybrid rdfcal version. ---- a subsection of property value datatypes [[ 4.3 Property Value Data Types ...................................32 4.3.3 Calendar User Address ....................................34 4.3.4 Date .....................................................34 4.3.5 Date-Time ................................................35 4.3.6 Duration .................................................37 4.3.9 Period of Time ...........................................39 4.3.11 Text ....................................................45 ]] (recurrence?) [[ 4.2.20 Value Data Types Parameter Name: VALUE Purpose: To explicitly specify the data type format for a property value. ]] [[ Description: The parameter specifies the data type and format of the property value. The property values MUST be of a single value type. For example, a "RDATE" property cannot have a combination of DATE- TIME and TIME value types. If the property's value is the default value type, then this parameter need not be specified. However, if the property's default value type is overridden by some other allowable value type, then this parameter MUST be specified. ]] [[ The properties in an iCalendar object are strongly typed. The definition of each property restricts the value to be one of the value data types, or simply value types, defined in this section. The value type for a property will either be specified implicitly as the default value type or will be explicitly specified with the "VALUE" parameter. If the value type of a property is one of the alternate valid types, then it MUST be explicitly specified with the "VALUE" parameter. ]] daml separates datatypes from object types. this means that calendar user address and date-time for example will be handled diffeently. let's start with the 4.3.3 Calendar User Address ....................................34 which we treat as a class. This is slightly odd modelling. We've seen that the cal-address has a common name and a calendar user type. this makes it seem like calling this object calendar user address is conflating the address of a calendar user with the calendar user themsleves. howevwer we follow as closely as possible the ical spec here, and put this asside for the moment. [[ Formal Definition: The value type is as defined by the following notation: cal-address = uri Description: The value is a URI as defined by [RFC 1738] or any other IANA registered form for a URI. When used to address an Internet email transport address for a calendar user, the value MUST be a MAILTO URI, as defined by [RFC 1738]. No additional content value encoding (i.e., BACKSLASH character encoding) is defined for this value type. ]] how do we model this restriction in daml? daml can place restrictions on datatypes *properties* in the schema. so we could break out the cal-address into cal-user object with a property of adress, that we could then restrict the value of. It's tempting here just to say, well in RDF (and DAML) resources are represented by uris, therefore the value of cal-address (as an object) can just be a resource. Maybe this would be ok. Michael Arick disagreed with me; he thinks its the syntactic form of the uri that matters in this case, not the name of the thing it refers to. so we could do this: we could alternatively treat it like a datatype property, with the object called cal-user or somesuch: cal-address is a property of cal-user pointing to a uri ---- Other datatypes time/dates/durations etc 4.3.4 Date .....................................................34 4.3.5 Date-Time ................................................35 4.3.6 Duration .................................................37 Time ?? 4.3.9 Period of Time ...........................................39 these should already be covered by xml datatypes - see http://www.w3.org/TR/xmlschema-2/#duration http://www.w3.org/TR/xmlschema-2/#dateTime http://www.w3.org/TR/xmlschema-2/#time http://www.w3.org/TR/xmlschema-2/#date so we should simply be able to use these definitions in defining properties which use these dartatypes. however.... duration: http://www.w3.org/TR/xmlschema-2/#duration xsd: PnYnMnDTnHnMnS (iso 8601 extended format) can have a preceeding negative sign. truncated forms are ok. P must always be there; T must not be there if no time present. ical: PnWnDTnHnMnS +/- etc datetime xsd: http://www.w3.org/TR/xmlschema-2/#dateTime CCYY-MM-DDThh:mm:ss [[ [Definition:] dateTime represents a specific instant of time. The ˇvalue spaceˇ of dateTime is the space of Combinations of date and time of day values as defined in § 5.4 of [ISO 8601]. ]] [[ CCYY-MM-DDThh:mm:ss where "CC" represents the century, "YY" the year, "MM" the month and "DD" the day, preceded by an optional leading "-" sign to indicate a negative number. If the sign is omitted, "+" is assumed. The letter "T" is the date/time separator and "hh", "mm", "ss" represent hour, minute and second respectively. Additional digits can be used to increase the precision of fractional seconds if desired i.e the format ss.ss... with any number of digits after the decimal point is supported. The fractional seconds part is optional; other parts of the lexical form are not optional. To accommodate year values greater than 9999 additional digits can be added to the left of this representation. Leading zeros are required if the year value would otherwise have fewer than four digits; otherwise they are forbidden. The year 0000 is prohibited. ]] [[ This representation may be immediately followed by a "Z" to indicate Coordinated Universal Time (UTC) or, to indicate the time zone, i.e. the difference between the local time and Coordinated Universal Time, immediately followed by a sign, + or -, followed by the difference from UTC represented as hh:mm (note: the minutes part is required). ]] ical: 4.3.5 Date-Time CCYYMMDDTHHMMSS date CCYYMMDD http://www.w3.org/TR/xmlschema-2/#date [[ [Definition:] date represents a calendar date. The ˇvalue spaceˇ of date is the set of Gregorian calendar dates as defined in § 5.2.1 of [ISO 8601]. Specifically, it is a set of one-day long, non-periodic instances e.g. lexical 1999-10-26 to represent the calendar date 1999-10-26, independent of how many hours this day has ]] [[ An optional following time zone qualifier is allowed as for dateTime. To accommodate year values outside the range from 0001 to 9999, additional digits can be added to the left of this representation and a preceding "-" sign is allowed. ]] time: ical: 4.3.12 Time HHMMSS http://www.w3.org/TR/xmlschema-2/#time [[ [Definition:] time represents an instant of time that recurs every day. The ˇvalue spaceˇ of time is the space of time of day values as defined in § 5.3 of [ISO 8601]. Specifically, it is a set of zero-duration daily time instances. ]] [[ The lexical representation for time is the left truncated lexical representation for dateTime: hh:mm:ss.sss with optional following time zone indicator. For example, to indicate 1:20 pm for Eastern Standard Time which is 5 hours behind Coordinated Universal Time (UTC), one would write: 13:20:00-05:00. See also ISO 8601 Date and Time Formats (§D). ]] --- so - there are a few problems. one is just a syntactic format, which can be redefined. one is a syntactic problem that is also a modelling problem. xsd allows utc offsets in dates, time, and date-times, as well as these with no timezones and utc only. Icalendar does not allow utc offsets. for now, I will use the xsd datatypes when defining properties which use them lower down. This is a serious difference though between the 2 datatype models for time, date etc. icalendar spends a great deal of time describing models of timeszones, which I do not examine here. -- Component properties component props I will use are: 4.8 Component Properties ........................................77 4.8.1 Descriptive Component Properties .........................77 4.8.1.5 Description ..........................................81 4.8.2 Date and Time Component Properties .......................90 4.8.2.2 Date/Time End ........................................91 4.8.2.4 Date/Time Start ......................................93 4.8.2.5 Duration .............................................94 4.8.4 Relationship Component Properties .......................102 4.8.4.1 Attendee ............................................102 4.8.4.6 Uniform Resource Locator ............................110 -- 4.8.1.5 Description ..........................................81 [[ Property Name: DESCRIPTION Purpose: This property provides a more complete description of the calendar component, than that provided by the "SUMMARY" property. Value Type: TEXT Property Parameters: Non-standard, alternate text representation and language property parameters can be specified on this property. Conformance: The property can be specified in the "VEVENT", "VTODO", "VJOURNAL" or "VALARM" calendar components. The property can be specified multiple times only within a "VJOURNAL" calendar component. Description: This property is used in the "VEVENT" and "VTODO" to capture lengthy textual decriptions associated with the activity. This property is used in the "VJOURNAL" calendar component to capture one more textual journal entries. This property is used in the "VALARM" calendar component to capture the display text for a DISPLAY category of alarm, to capture the body text for an EMAIL category of alarm and to capture the argument string for a PROCEDURE category of alarm. ]] The first part of this is simple, I think.... all we have to do is determine whether its a dt or ob property 'text' sounds like a literal in RDF or maybe like a string in xsd if it's a literal, des that make it a dt property or an oject property? (/me realizes I don't know) /me looks at http://www.daml.org/2001/03/reference.html and at http://www.daml.org/2001/03/daml+oil.daml we have [[ ObjectProperty if P is an ObjectProperty, and P(x, y), then y is an object. DatatypeProperty if P is a DatatypeProperty, and P(x, y), then y is a data value. ]] i.e. depends whethe it is an 'object' or a 'data value' help! I'm going to assume its (a) an rdfs:Literal and (b) an object, because I feel more comfortable with them hang on, since literals aren't resources in rdf, maybe I can't do that. * looking for indications that text needs to have resources hanging off it h'm, yes: [[ 4.2.10 Language Parameter Name: LANGUAGE Purpose: To specify the language for text values in a property or property parameter. Format Definition: The property parameter is defined by the following notation: languageparam = "LANGUAGE" "=" language language = ]] (but xml should do that for you. anything else?) in any case that's text, not TEXT I'm going to assume it's a dataype property but use literal as the value for the datatype. I don't know if that's allowed, or whether it has to be defined in xsd. This property provides a more complete description of the calendar component, than that provided by the "SUMMARY" property. aaarrrgggh! * notice this: [[ Property Parameters: Non-standard, alternate text representation and language property parameters can be specified on this property. ]] this conflicts with my plan to make alternate text and the like properties of the objects rather than of the properties. ok, what about this: This property provides a more complete description of the calendar component, than that provided by the "SUMMARY" property. I've made it an objectProperty, because it's not a datatype defined in xsd. I've no idea if this is correct, but I need to move on. The second problem (which I though was the harder one) is a modelling problem with what objects descriptio can be used. [[ Conformance: The property can be specified in the "VEVENT", "VTODO", "VJOURNAL" or "VALARM" calendar components. The property can be specified multiple times only within a "VJOURNAL" calendar component. Description: This property is used in the "VEVENT" and "VTODO" to capture lengthy textual decriptions associated with the activity. This property is used in the "VJOURNAL" calendar component to capture one more textual journal entries. This property is used in the "VALARM" calendar component to capture the display text for a DISPLAY category of alarm, to capture the body text for an EMAIL category of alarm and to capture the argument string for a PROCEDURE category of alarm. ]] translation: * it CAN be used in all cal-components EXCEPT free/busy and timezone * it CAN ONLY be specified more than once in a VJOURNAL * it has different meaning in VEVENT and TODO from VJOURNAL and completely different meanings for VALARM! the third should really be captured by a different property? but maybe we can describe the first two in DAML. (1) * it CAN be used in all cal-components EXCEPT free/busy and timezone in RDF I would (if I cared sufficinetly) have a supercalss of all the cal components called cal-component, and another superclass of all except free/busy and timezone, and make this new superclass the domain of description. Couldn't do anything about the vjournal element diference, so wouldn't bother to model its implicit difference to vevent, vtodo in daml....is there a better way than this:? the superclass of every cal-component the superclass of every cal-component - not entirely satisfactory. ---- [[ 4.8.2 Date and Time Component Properties .......................90 4.8.2.2 Date/Time End ........................................91 4.8.2.4 Date/Time Start ......................................93 ]] [[ 4.8.2.2 Date/Time End Property Name: DTEND Purpose: This property specifies the date and time that a calendar component ends. 1. Value Type: The default value type is DATE-TIME. The value type can be set to a DATE value type. 2. Property Parameters: Non-standard, value data type, time zone identifier property parameters can be specified on this property. 3. Conformance: This property can be specified in "VEVENT" or "VFREEBUSY" calendar components. ]] 1. so its value is date or date-time: * utterly unclear to me about when to use datatypeProperty and object property [[ DAML+OIL divides the world up into objects, which are elements of DAML classes, and datatype values, i.e., values that come from XML Schema datatypes, like the integer 4. ]] that seems rather arbirtrary range is a date or a datetime. [[ It is allowed in DAML+OIL to state multiple ranges. Again, such multiple statements must be read conjunctively: the values of the property must satisfy all the range statements (and similarly for multiple domain statements). ]] darn, I want 'or' not 'and'. do I have to define a superclass of date and datetime, and use that as a range? - by Michael Arick: [[ ]] so we can have (if we're inisting on daml): rdfs:label="TimeEntry" rdfs:comment="Date or Date-Time"/> but, that means that we'll have to make xsd:date a subclass of timeentry. can we do that? I guess so. But does that make it a daml rather than a xsd object? all the DatatypeProperties pointing to it will really be ObjectPropeties. I think probably the best thing is to keep rdfs:Property or define the daml equivalent, and use that for all these properties. The distinction is making things worse not better. So ical:prop from now on (with the understanding that its basically rdfs:Property). (identical to rdfs version) -? could I have done it differently in daml? e.g. create a range that was anon class which had subclasses xsd:date and xsd:dateTime? * giving up on this for now. however we do dtend, we also do dtstart. -- ----trying to summarise up to here - could do more on ical, but need to get started on skical. --- todo: 4.8.4.7 Unique Identifier (for the calendar component) recurrance? --- 2002-03-15 danbri mde me realize that uid is a good candidate for daml:unqiue property, so am looking at that and then moving to skical. [[ 4.8.4.7 Unique Identifier Property Name: UID Purpose: This property defines the persistent, globally unique identifier for the calendar component. Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property. Conformance: The property MUST be specified in the "VEVENT", "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. Description: The UID itself MUST be a globally unique identifier. The generator of the identifier MUST guarantee that the identifier is unique. There are several algorithms that can be used to accomplish this. The identifier is RECOMMENDED to be the identical syntax to the [RFC 822] addr-spec. A good method to assure uniqueness is to put the domain name or a domain literal IP address of the host on which the identifier was created on the right hand side of the "@", and on the left hand side, put a combination of the current calendar date and time of day (i.e., formatted in as a DATE-TIME value) along with some other currently unique (perhaps sequential) identifier available on the system (for example, a process id number). Using a date/time value on the left hand side and a domain name or domain literal on ]] [[ Purpose: This property defines the persistent, globally unique identifier for the calendar component. Value Type: TEXT ]] because it's globally unique, the uid when used will always refer to that node. so we can say that any time we see that uid, that means that node is present. * getting confused about uniqueproperty and unambigious Property. http://www.daml.org/2001/03/daml+oil-walkthru.html [[ Since a UniqueProperty has cardinality 1, each subject uniquely identifies the object (value) of the property (ie. the identity of a person determines their mother). Conversely, an UnambiguousProperty is a property whose object uniquely identifies its subject. (The inverse of any UniqueProperty is always an UnambiguousProperty). ]] a shoesize is an example of uniqueProperty. every person has one shoe size value conversely, the shoesize value and property of shoesize is enough to identify the person...?? p1 shoessize 3 p2 shoessize 3 nope. shoesize and value do not mean same person. every personalEmail belongs to one person (at a give time) p1 mbox bla1@bla p2 mbox bla1@bla yes p1 and p2 are the same person if the value of a property is a unique identifier, then (I think) we have an unambiguous property. therefore we can say: I won't specify the doain, because although used here for VEVENTs, could be useful elsewhere, and I dont know how to specify a local domain. changing my mind, reading this: [[ Conformance: The property MUST be specified in the "VEVENT", "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. ]] the superclass of calcompoennts that are required to have uids or maybe... I was going to write sameClassAs, but I think that would mean that the set of things with exactly one UID was exactly the same as the set of CAL-COMPONENT-UID-MUST-NO-VTZ_VALARMs, which isn't right is it right to say that the same event cannot have 2? perhaps mincardinailty is truer to the words, although I think cardinality is truer to the intention. * remembering that unique property===cardinality=1 what does this mean for the inverse of a unqiue property (our unambiguousproperty) I think it means there can only be one of the inverse too. * give up for now. ----------------------------------------------------------------- SKICAL. http://www.ietf.org/internet-drafts/draft-many-ical-ski-05.txt SkiCal property parameters - all the 'must' etc stuff is summarised in a table. [[ 3.1 Item Parameter Name: ITEM Purpose: To specify the name of a specific auxiliary element or part of a SkiSource. ]] from the examples this seems to be an object and a description of an object: [[ BOOKINGS;PRXITEM="SR:Reptile Room":only outside the Reptile Room! RECOMMENDED;ITEM="The evening tours":Warm sweater or Jacket PROHIBITED;ITEM="During the magic show":Flash cameras BOOKINGS;PRXITEM="K:New Years Eve Dinner";OPREF=NYD: 1-800-256 2222. ]] @@more needed@@ [[ 3.2 Namespace Reference Parameter Name: NSREF Purpose: To point to a namespace declaration within the same SkiCal object ]] [[ Description: This parameter specifies a prefix that matches a prefix declared as a NAMESPACE property parameter value. The NSREF parameter provides a method for relating the value of the property on which it is used to the appropriate namespace. It is expected that publishers wishing to optimize interoperability will choose values from enumerated lists of value-terms. These lists can be utilized for constraining the values of both properties and property parameters. The declaration for the URI of such a list is accomplished using the NAMESPACE property. The NAMESPACE property can also assign a shorthand prefix to the URI value of the NAMESPACE and this prefix can be referenced using the NSREF property parameter. ]] - looks like it needs to be declared elsewhere? - I'm unclear what the namespace refers to: [[ RESOURCES;NSREF="QLL":HL984 projector PERSONS;NSREF="WW":Bill Clinton PERSONS;SKIROLE="orchester-member";NSREF="WW":Bill Clinton PERSONS;PRXSKIROLE="OM:orchester-member";NSREF="WW":Bill Clinton REQUIRED;NSREF="TNT":NASCT Certificate CATEGORIES;NSREF="SSV";LANG=se:Vuxen Utbilding - Biometrics II ]] if WW:Bill Clinton, that's not a qname... ?? --- [[ 3.3 OPTIMESET reference Parameter Name: OPREF Purpose: To point to an OPTIMESET declaration. ]] OPTSET is an opening times set, I think. [[ Description: This parameter specifies an ID that matches an OPTIMESET ID as declared in the OPTIMES property. This parameter provides a method for relating the value of the property within which it is used to the appropriate OPTIMESET. ]] i.e. refers to the identifier for a particular set of opening times (rules for generating time intervals?) looks useful. --- [[ 3.4 SKiROLE Parameter Name: SKIROLE Purpose: To clarify the role of Property values in a SkiCal object. The use of the ROLE Property Parameter as defined in RFC-2445 [3] Section 4.2.16 Participation Role is constrained to specific component properties and specific default values. To avoid incompatibility, SkiCal defines a new property parameter - SKIROLE. ]] - a case of over-general range contraints in icalendar? [[ Description: The SKIROLE property parameter declares or clarifies the role of Persons, Organizations, Things, or Thinks declared as the value for the Component Property ]] there are a bunch of constrained values for this depending what sort of property they are used on. ------------ 4. SkiCal Specific Property Value Data Types 4.1 The OpeningTimes Set [[ An iCalendar VEVENT component can only describe one complete date- time set and its eventual recurrences, such as office meetings or lunch appointments. Using the SkiCal OPTIMESET of datetime values; OPTERM, OPSEASONS, OPDAYS, OPHOURS and OPMINUTES and OPSECONDS, individual SkiCal properties MAY be qualified with date and time values. For example, through the use of the OPTIMESET a publisher could within one calendar object describe not only the general date-times of a conference, but also when a refreshment bar was open, the telephone times for a help desk, the last date for submitting papers, and the opening times of the conference hall itself. Or in another example, through the use of this OPTIMESET a publisher could within one calendar object describe the operating times of a petrol station, differentiating between levels of service such as when a mechanic was on duty, when the convenience store was open or full service available. ]] this seems to mean we can attach opening times to properties - I'm not sure what a property consists of in skical/ical though. basically a way of giving a specific description of a set of opening times an identifier. [[ 4.1.1 Terms used in the OPTIMESET data value declaration OPEN: Depending upon the property value being qualified, OPEN may indicate open, accessible, in-force, operative, available or any comparable state. ]] that's kind of odd.... also NOT-OPEN, NOT-DETERMINABLE some stuff about inclusive and exclusive dates and a syntactic hack for distinguishing them. I'm having a lot of trouble working out the underling model of skical. A version in UML would be very helpful. I'm not the person to do it though. many of the 'terms used in the OPTIMESET data value declaration' are not formally defined anywhere else in the document. So I better look at them here... [[ DATE-TIME VALUE PAIR: Two date-time values separated by one or more solidus "/" characters. Value-pairs are either END- INCLUSIVE or END-EXCLUSIVE. ]] there are date-times, and date-time pairs date-times can be start- or end-inclusive or exclusive [[ END-EXCLUSIVE 170000/180000 ]] what happens if start and end exclusive or inclusive is not specified? how do you tell about start at all? is the // enough or do you need to specify 'START_'? bah! [[ PERIOD-EXPLICIT / DURATION-EXPLICIT: This SkiCal memo stipulates the use of either period-explicit or duration- explicit value-pairs. Though at first glance the difference may seem to be only representational, these value-pair declarations must not be treated as interchangeable. See below. PERIOD-EXPLICIT: A period of time that is defined by a specific start and a specific end. ]] the actual duration is calculated from a period explicit, taking into account all possibe tz changes, daylight savings fluctuations etc. == start+end. in duration-explicit, the period of time is fixed: the start and end times are calculated from that. == start+duration or end+duration. [[ TWO USES of ISO8601 TIME-DATE PERIODS: In duration-specific value-pairs the amount of time represented must unambiguously be reducible to a number of seconds. For example P2D is the equivalent of PT172800S (1 day = 86400 seconds. For this reason RFC2445 has limited the possible members of this set to Weeks, Days, Hours, Minutes and Seconds, considering the ambiguity involved in the length of a Year or a Month or century. At the same time the same members of the complete set; Centuries, Years, Months, Weeks, Days, Hours, Minutes, Seconds and fractions thereof, make convenient units for reoccurrences which are actually period-explicit. For example; reoccurrences on the third of every month will give instances in time of unequal duration from each other. In this memo the contents of the CYCLE attribue use the full ISO8601 set for reoccurrences. ]] [[ 4.1.2 Term of the OPTIMESET Value Name: OPTERM Purpose: This value type is used to express an interval of time or a point in time. The OPTERM value type when specified is used in computing the OPTIMESET. ]] [[ The opterm value-type is unique in the OPTIMESET insomuch as it is "anchored" or fixed to the common era. No other OPTIMESET value-type shares this function. Without the Opterm, other value-types can never point to a specific time or date - only infinite free floating reoccurrences such as every Monday. On the other hand Opterms can not reoccur. ]] [[ OPTERM serve the purpose of anchoring and constraining the reoccurrences of it contents, but is also suitable for declaring single events or points in time. In the later case the OPTERM will have no contents. ]] why are the formal definitions in XML suddenly? (checks if have been in entire doc) ok, no, but: [[ Format Definition: The OpeningTimes set is defined by the following xml 1.0 DTD: ]] I guess the idea is to point at the openingtimes list? the rest is not in xml. ok, this makes more sense. there's an opterm object, with properties range, id, idref, state, rangevaluetype....some date-time stuff jdn (julian date number) (why?) network time protocol and some duration stuff. ---more detail, see if we can get a sense of the model. opterm - range -> optermvalue optermvalue == loads of stuff.... [I wonder if defining a bnf is a good goal for OWL?] optermvalue can be a period or duration explicit opterm - range -> optermvalue optermvalue -supercalss of PERIOD-EXPLICIT DURATION-EXPLICIT one or the other PERIOD-EXPLICIT->start->TIME-ENTRY ->END->TIME-ENTRY end can be a textual content as well, darn it ->END-TEXT->TERM-TEXT [[ term-text = "THISANDFUTURE" / "THISANDPRIOR" / "POINT" ]] ??maybe DTSTART/END? I wonder if all the dat-teme stuff can be lifted from rfc 2445? looks like date and datetime are the same [thinks: could create new date-type values out of xsd:int] for jdn, mjd and tp, we need to have a thing which timeentry and all these others are a subclass of. more general than time-entry as includes various floats. Union? ???? is skical-time-entry a datatype?....TIME_entry is a datatype... define each of those extra ones as a datatype 2002-03-20 -- ?? or rather as a subclass of a datatype?? ??is that right...? optermdur_explvalue [[ optermdur_explvalue = (date / date-time) "/" rangeperiod ]] date, date-time are from rfc 2445. is range period also? [[ rangeperiod = (["+"] / "-") "P" (dur-week / dur-day / dur-time ) dur-week = 1*DIGIT "W" dur-day = 1*DIGIT "D" dur-time = "T" (dur-hour / dur-minute / dur-second) dur-hour = 1*DIGIT "H" [dur-minute] dur-minute = 1*DIGIT "M" [dur-second] dur-second = 1*DIGIT "S" ]] from RFC 2445 [[ dur-value = (["+"] / "-") "P" (dur-date / dur-time / dur-week) dur-date = dur-day [dur-time] dur-time = "T" (dur-hour / dur-minute / dur-second) dur-week = 1*DIGIT "W" dur-hour = 1*DIGIT "H" [dur-minute] dur-minute = 1*DIGIT "M" [dur-second] dur-second = 1*DIGIT "S" dur-day = 1*DIGIT "D" ]] - they are different - skical is missing dur-day. Neither is the same as xsd, because that doesn't have week. however, I'm going to assume they are all the same for now, so we have change to so it covers both period-explicit and duration-explicit. [[ optermcontents = *( "OPSEASONS" / "OPDAYS" / "OPHOURS" / "OPMINUTES" / "OPSECONDS" ) ]] opterm contents are more properties of the opening times container. something like: OPTERM - optermcontents ->OPTTERM-CONTENTS_VALUE they are objects which can have states, and times and ranges attached to them. [[ 4.1.3 Seasons of the OPTIMESET Value Name: OPSEASON ]] ........... oh boy....... [[ Purpose: This value type is used to express an interval of time. The Opseasons value-type when specified is used in computing the OPTIMESET. The value representation of OPSEASONS is ISO8601:2000 Section 5.2.1.3. sub-section d. "A specific day of the month", Basic Format "--MMDD", modified in this note by the exclusion of "--" to be "MMDD" ]] - similar structurally to opterm. [so I think how this is modelled is by having an overall period for which the opening hours are specified (opterm), and then more detail about some or all of months, days, etc etc.] might be some forma of subclass onnectiobn betweenthese various opterms, but leave for now. superclass of all the OPTERM things OPSEASONS must have range and state: optional are id, idref and cycle (same for all the others tho day has an extra) state we've had before; also range, if, and idref, for opterm, but I didnt write it up. this implies we should have a rel bet opterm and OPTERM-CONTENTS-VALUE. [maybe anoyther way to do it is restrict domain and range locally. but wouldn't find how to do that w domain.] hm, but range is diffrent in each case - diff meaning. For OPTERM: opterm - range -> optermvalue for opseasons opseasons - range -> opseasonsvalue OPDAYS: OPHOURS: OPMINUTES: OPSECONDS: ?does this mean that - there has to be a range on opseconds - *and* if it's there it has to be to OPSECONDS-VALUE? (hope so) - all are required...dunno if can have more than one. state applies to all our opterm-generics id and idref are optional for all OPTERM-GENERICs and refer to text. TEXT? not clear. assume so. need to do opseasons-value etc [[ opseasonsper_explvalue = impliedyeardate "/" ["/"] ( impliedyeardate / seasons-text ) opseasondur_explvalue = impliedyeardate "/" rangeperiod ]] this is basically the same as for OPTERM, but impliedyeardate doesnt have a year, and seasons-text isnt defined... how do we do impliedyeardate? it's probably within the scope of iso 8601 date-time, but we need to say its a date without ayear. xsd must have a year. xsd gmonthday, gday are't right - they're repeating. is this repeating? - no -it's got an implicit year, from the higher unti of range. http://www.w3.org/TR/xmlschema-2/#isoformats [[ [ISO 8601] supports a variety of "truncated" formats in which some of the characters on the left of specific formats, for example, the century, can be omitted. Truncated formats are, in general, not permitted for the datatypes defined in this specification with three exceptions. The time datatype uses a truncated format for dateTime which represents an instant of time that recurs every day. Similarly, the gMonthDay and gDay datatypes use left-truncated formats for date. The datatype gMonth uses a right and left truncated format for date. ]] hm, truncated dates may have several meanings. or perhaps its the same thing, with the perid of repetition being the higher level value ** 'smaller' units of time go inside the larger ones. ok, use http://www.w3.org/TR/xmlschema-2/#gMonthDay plus a time? can we have a gMonthDay+time in xsd? * learning about xsd a little, deciding to leave this for a while. it's not clear whether times can also be truncated, though could write one....later maybe At any rate, the general format will be: one or the other (note made-up xds datatypes) - maybe season-text-choice - some missing text from skical here and so on for day, hour, minute and second. three parts are left ion this section: rangevaluetype the recursive thing - optermcontents, opseasonscontents, etc cycleperiod * thinking about the recursive thing - this is the most interesting to me. basically, opterm-generics all have contents, but each can only have in its contents optclasses pertaining to units of time which are smaller than the current one. can we do this in a clever way in daml? I don't think so. All we can do is repeatedly define supclasses of subsets of the opt-generics, which fit appropriately into the heirarchy of allowed types, maybe using contents as a generic property but with specific ranges. so, redo opterm-contentsvalue, as the top ione of these (diff name tho) superclass of all the things smaller than OPTERM superclass of all the things smaller than OPSEASON superclass of all the things smaller than OPDAYS superclass of all the things smaller than OPHOURS then the contents property. For OPTERM: opterm - contents -> OPTERM-SEASONS-AND-SMALLER for opseasons opseasons - range -> OPTERM-DAYS-AND-SMALLER OPDAYS: OPHOURS: OPMINUTES: -- for rangevaluetype, this appears in opdays and opterm only, with different fixed lists of values in each case so for opterm we have and for optdays we have finally, in this section, cycleperiod. this is a property of opseasons, days, hours, mins secs, i.e #OPTERM-SEASONS-AND-SMALLER, which points to a duration: [[ cycleperiod = "P" (dur-year / dur-month / dur-week / dur-day / dur-time ) ]] ---end of optset stuff. [[ 4.2 SkiCal specific Calendar Component The body of an iCalendar object consists of a sequence of calendar properties and one or more calendar components. The calendar properties are attributes that apply to the calendar as a whole. The calendar components are collections of properties that express a particular calendar semantic. For example, the calendar component can specify an event, a to-do, a journal entry, time zone information, or free/busy time information, or an alarm. A SkiCal extended iCalendar object may include a "VOPTIME" calendar component as defined by the following notation: ]] so a VOPTME is: [[ The "OPTIME" calendar component is identical to the "VEVENT" calendar component with the exception that the Date-time related properties such as DTSTART, DTEND and DURATION have been removed and replaced by the DTOPEN property. ]] so we can I think subclass cal-component. dtopen seems to be a textual description of opening times. now we need to look at the properties of voptime. WHAT [[ 4.8.1.2 Categories 4.8.1.5 Description - The description property in RFC2445 can be used to hold any sort of WHA information. 4.8.1.11 Status 4.8.1.12 Summary - The summary property in RFC2445 can be used to hold any sort of WHA information. ]] and also... 4.3.1.1 Title [[ Description: Public SkiSources often have titles . The title may not be directly descriptive of the SkiSource. The Title might be abstract in nature or it might be a copyrighted name that an owner wishes to see included in the calendar object. The following example illustrates the difference between SUMMARY and TITLE: A photo exhibition by photographer Collier Schorr in New York City called "Excuse Me While I Kiss th ]] [I'm not sure how to handle laguage tagging. I'm hoping xml will give us this, but I'm not sure it does...] [[ 4.3.1.2 Persons * sees half of skical still to go, takes a break.... ************ Modelling problems * when there are 2 typed objects as alternatives, is it better to have the same property pointing to both or different properties? e.g PERIOD-EXPLICIT->start->TIME-PERIOD ->END->TIME-PERIOD end can be a textual content as well, darn it END? * how on earth do you mix and match xsd terms with daml/rdf? the problem is that xsd datatypes describe syntax not objects. We need to make them objects, maybe by subclassing into daml/rdf space. its weird anyway, because for example you could create a spcial url in xsd space, subclass it into daml/rdf space, and then use it as a replacement for a resource. ...but... then you get weirdo stuff happening - rdf:value or somesuch for almost every resource... * OR would be nice in daml (obviously would make translation from BNF easier) (otherwise you end up creating loads of superclasses of dijoinunions of subsections of the object space. I think this is pretty ugly. on the other hand I wouldnt know how else to do it.) * why can't objects have values, and not just properties??? * datatyping is bottom up, and class heirarchies are top-down. * datatyping puzzling: string and literal anyuri and resource should you say that #description isa datatypeProperty value xsd:string #description isa objectProperty value rdf:Literal #uri-id isa datatypeProperty value xsd:anyuri #uri-id isa objectProperty value rdf:Resource ? which is right? ************