- 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