- From: Antoni Mylka <Antoni.Mylka@dfki.uni-kl.de>
- Date: Tue, 10 Oct 2006 23:29:44 +0200
- To: www-rdf-calendar@w3.org
I have written about the owl-time ontology yesterday. It seems that the most unobtrusive way to incorporate it into ical-rdf would be to extend the Value_... types. They are undefined at the moment. It would be pretty straightforward to add something like this: <owl:Class rdf:ID="Value_DATE-TIME"> <rdfs:subClassOf rdf:resource="http://www.w3.org/2006/time#Instant"/> </owl:Class> <owl:class rdf:ID="Value_DATE"> <rdfs:subClassOf rdf:resource="http://www.w3.org/2006/time#Instant" /> </owl:Class> <owl:Class rdf:ID="Value_PERIOD"> <rdfs:subClassOf rdf:resource="http://www.w3.org/2006/time#Interval" /> </owl:Class> <owl:Class rdf:ID="Value_DURATION"> <rdfs:subClassOf rdf:resource="http://www.w3.org/2006/time#DurationDescription"/> </owl:Class> No other changes in the ontology would be necessary. Examples: DTSTAMP:20030109T23909Z fromIcal.py <dtstamp rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime" >2003-01-09T12:39:09Z</dtstamp> One could use the convenience property inXSDDateTime <dtstamp> <owltime:Instant> <owltime:inXSDDateTime> 2003-01-09T12:39:09Z </owltime:inXSDDateTime> </owltime:Instant> </dtstamp> or: one might be more exact and use the owl-time dateTimeDescription <dtstamp> <owltime:Instant> <owltime:inDateTime> <owltime:DateTimeDescription> <owltime:unitType rdf:resource="http://www.w3.org/2006/time#unitSecond"/> <owltime:year>2003</owltime:year> <owltime:month>1</owltime:month> <owltime:day>9</owltime:day> <owltime:hour>12</owltime:hour> <owltime:minute>39</owltime:minute> <owltime:second>9</owltime:second> <owltime:timeZone rdf:resource="http://www.w3.org/2006/timezone-world#ZTZ/> </owltime:DateTimeDescription> </owltime:inDateTime> </owltime:Instant> </dtstamp> Example with a timezone DTSTART; TZID=/softwarestudio.org/Olson_20011030_5/Europe/London:20030122T170000 fromIcal.py <dtstart rdf:datatype="http://www.w3.org/2002/12/cal/tzd/Europe/London#tz" >2003-01-22T17:00:00</dtstart > proposition: <dtstamp> <owltime:Instant> <owltime:inDateTime> <owltime:DateTimeDescription> <owltime:unitType rdf:resource="http://www.w3.org/2006/time#unitSecond"/> <owltime:year>2003</owltime:year> <owltime:month>1</owltime:month> <owltime:day>22</owltime:day> <owltime:hour>17</owltime:hour> <owltime:minute>0</owltime:minute> <owltime:second>0</owltime:second> <owltime:timeZone rdf:resource="http://www.w3.org/2006/timezone-world#ZTZ"/> </owltime:DateTimeDescription> </owltime:inDateTime> </owltime:Instant> </dtstamp> Duration: DURATION:P15DT5H0M20S fromIcal.py: <duration rdf:parseType="Resource" ><rdf:value rdf:datatype="http://www.w3.org/2001/XMLSchema#duration" >PT1H</rdf:value ></duration > owl-time vocabulary <duration> <owltime:DurationDescription> <owltime:days>15</owltime:days> <owltime:hours>5</owltime:hours> <owltime:seconds>20</owltime:seconds> </owltime:DurationDescription> </duration> Period value. The only property that has a PERIOD value type is FREEBUSY. FREEBUSY;VALUE=PERIOD:19971015T050000Z/PT8H30M, 19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M fromIcal.py doesn't seem to support VFREEBUSY components at all. ical2rdf.pl does it this way: <freebusy>19971015T050000Z/PT8H30M,19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M</freebusy> mimedir-parser is a little more intelligent: <freebusy>19971015T050000Z/PT8H30M</freebusy> <freebusy>19971015T160000Z/PT5H30M</freebusy> <freebusy>19971015T223000Z/PT6H30M</freebusy> owl-time vocabulary would enable the VFreebusy to be expressed it in the following way: <freebusy> <owltime:Interval> <owltime:hasBeginning> <owltime:inXSDDateTime>2003-01-09T12:39:09Z</owltime:inXSDDateTime> <!-- one could also use the more detailed DateTimeDescription --> </owltime:hasBeginning> <owltime:hasDurationDescription> <owltime:DurationDescription> <owltime:hours>8</owltime:hours> <owltime:minutes>30</owltime:minutes> </owltime:DurationDescription> </owltime:hasDurationDescription> </owltime:Interval> </freebusy> <!-- and similar entries for the remaining two freebusy periods --> Pros: More detailed time description. Potential solution to the timezone problem. (The w3c-supported timezone ontology and database). Cons: The OWL-Time ontology uses a timezone ontology developed by the same authors themselves. It seems to be more detailed than TZ database. It does capture much more obscure geographical details but so far I haven't found any applications that actually use it. The DurationDescription class doesn't support negative durations (as the XSD duration datatype does). One would have to find a workaround, (or introduce this concept into owl-time). The timeZoneProperty of the owl-time ontology points to a timezone, not to a Region. That would mean that the daylight saving information is lost. Or maybe I misunderstood something. I posted these issues to the public-swbp-wg@w3.org mailing list. Awaiting comments Antoni Mylka antoni.mylka@dfki.uni-kl.de
Received on Tuesday, 10 October 2006 21:30:01 UTC