You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1316 lines
52 KiB
1316 lines
52 KiB
<?xml version="1.0" encoding="utf-8"?>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<head>
|
|
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
|
|
<title>RDF Calendar - an application of the Resource Description Framework
|
|
to iCalendar Data</title>
|
|
<style type="text/css" title="screen" media="screen">
|
|
/* <![CDATA[ */
|
|
blockquote
|
|
{
|
|
width: 80%;
|
|
margin: auto;
|
|
border-color: #69C;
|
|
border-width: 0px 0px 0px 3px;
|
|
border-style: none none none solid;
|
|
padding: 0.5em 1em;
|
|
text-align: justify;
|
|
background-color: #F3F3F3;
|
|
}
|
|
|
|
blockquote pre
|
|
{
|
|
border: none;
|
|
width: 100%;
|
|
background-color: #F3F3F3;
|
|
}
|
|
|
|
p { text-indent: 15pt; }
|
|
|
|
.footnotes
|
|
{
|
|
font-size: smaller;
|
|
background-color: #fef;
|
|
width: 70%;
|
|
}
|
|
|
|
address
|
|
{
|
|
text-align: right;
|
|
text-indent: 15pt;
|
|
}
|
|
|
|
pre
|
|
{
|
|
width:80%;
|
|
margin:auto;
|
|
background-color: #fff;
|
|
border-color: #69C;
|
|
border-width: 1px 1px 1px 3px;
|
|
border-style: solid;
|
|
padding: 1em;
|
|
}
|
|
|
|
|
|
/* ]]> */
|
|
</style>
|
|
<link rel="stylesheet" href="/2005/09/table.css" />
|
|
</head>
|
|
|
|
<body xml:lang="en" lang="en">
|
|
<p><a href="./">RDF Calendar</a></p>
|
|
|
|
<h1>RDF Calendar - an application of the Resource Description Framework to
|
|
iCalendar Data</h1>
|
|
<dl>
|
|
<dt>This version</dt>
|
|
<dd>$Revision: 1.40 $ of $Date: 2005/10/03 20:36:05 $<br />
|
|
editor's draft; subject to change without notice</dd>
|
|
<dt>Stable Published Version</dt>
|
|
<dd><a href="http://www.w3.org/TR/rdfcal/">29 September 2005</a></dd>
|
|
<dt>Authors</dt>
|
|
<dd><a href="/People/Connolly/">Dan Connolly</a> and <a
|
|
href="http://ilrt.org/people/cmlm/">Libby Miller</a></dd>
|
|
</dl>
|
|
|
|
<h2> Abstract</h2>
|
|
<p>This report discusses an effort to apply the Resource Description
|
|
Framework (RDF) to iCalendar data in order to integrate calendar data
|
|
with other Semantic Web data such as social networking data,
|
|
syndicated content, and multimedia meta-data. We demonstrate the
|
|
effectiveness of a test-driven approach to vocabulary development and
|
|
we discuss a number of social as well as technical issues.</p>
|
|
|
|
<div id="sotd">
|
|
<h3> Status of this document</h3>
|
|
<p>This is a draft for discussion in the <a
|
|
href="http://lists.w3.org/Archives/Public/www-rdf-calendar/">www-rdf-calendar</a>
|
|
mailing list, part of the <a
|
|
href="http://www.w3.org/2001/sw/interest/">Semantic Web Interest Group</a>.
|
|
It is subject to change without notice.</p>
|
|
|
|
<p>See also the <a href="http://www.w3.org/TR/rdfcal/">29 September
|
|
2005 publication as an Interest Group Note</a>.</p>
|
|
</div>
|
|
|
|
|
|
<div class="toc">
|
|
<h2 id="contents"> Contents</h2>
|
|
|
|
<ul>
|
|
<li><a href="#intro">1. Introduction</a></li>
|
|
<li><a href="#Collaborat">2. Collaboration challenges and
|
|
rewards</a></li>
|
|
<li><a href="#exsim">3. A simple example</a></li>
|
|
<li><a href="#ns-gnd">4. Namespaces: grounding terms in URI
|
|
space</a></li>
|
|
<li><a href="#comp">5. Calendar objects, components and files</a></li>
|
|
<li><a href="#L10136">6. Capitalization and naming conventions</a></li>
|
|
<li><a href="#collab">7. Choosing a namespace policy</a></li>
|
|
<li><a href="#Generating">8. Generating a schema from examples</a></li>
|
|
<li><a href="#Gleaning">9. Gleaning a schema from the specification
|
|
text</a></li>
|
|
<li><a href="#Extension">10. Extension Tokens and Product
|
|
Identifiers</a></li>
|
|
<li><a href="#L21805">11. Shop hours, recurring events and
|
|
timezones</a></li>
|
|
<li><a href="#Locations">12. Events, places, names, and
|
|
coordinates</a></li>
|
|
<li><a href="#testdr">13. Using RDF graph comparison for round-trip
|
|
testing</a></li>
|
|
<li><a href="#L1877">14. Related Work</a>
|
|
<ul>
|
|
<li><a href="#L1892">14.1. xCalendar</a></li>
|
|
<li><a href="#L1901">14.2. RSS event module</a></li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#conc1">15. Conclusions and future work</a>
|
|
<ul>
|
|
<li><a href="#L1879">15.1. hCalendar and microformats</a></li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#Acknowledg">16. Acknowledgements</a></li>
|
|
<li><a href="#L1962">17. References</a></li>
|
|
</ul>
|
|
</div>
|
|
|
|
<div>
|
|
<h2 id="intro">1. Introduction</h2>
|
|
|
|
<p>The Web did two things for sharing information with documents: first, HTML
|
|
and TCP/IP provided a neutral answer to the questions about which word
|
|
processor's format to use, which operating system, and which networking
|
|
technology; second, the Web integrated individual documents into a whole
|
|
information system so that if the information was already in the Web
|
|
somewhere, you could just link to it. HTML is feature-poor when compared to
|
|
other document formats, but the integration benefits of linking outweigh the
|
|
costs.</p>
|
|
|
|
<p>Fifteen years later, this works pretty well for documents. If you have a
|
|
document and someone asks you to provide it to each of a dozen different
|
|
people that each use different kinds of computers, you can just put it on the
|
|
Web in HTML and be reasonably sure they can all read it. But the integration
|
|
problem is still there for data. When a soccer coach distributes a schedule
|
|
for the season, each of the players has to re-key the information for their
|
|
calendar system if they want their computer to help them manage conflicts.
|
|
When an airline sends itineraries, each passenger manually processes them.</p>
|
|
|
|
<p>The problem is addressed at least in part by an Internet standard<sup><a
|
|
href="#std-note">st</a></sup> for calendar data, iCalendar[<a
|
|
href="http://www.w3.org/2002/12/cal/rfc2445">RFC2554</a>]. But it's not clear that iCalendar provides
|
|
sufficient integration benefits to outweigh the cost of migrating to open
|
|
systems from more mature closed calendaring systems. At a <a
|
|
href="http://www.w3.org/2001/sw/Europe/events/200210-cal/">Semantic Web
|
|
calendaring workshop</a> in October 2002, we explored the additional benefits
|
|
of applying the Resource Description Framework (<a
|
|
href="http://esw.w3.org/topic/RDF">RDF</a>) to iCalendar data, allowing us to
|
|
linked it with social networking data (<a
|
|
href="http://www.foaf-project.org/">FOAF</a>), syndicated content (<a
|
|
href="http://purl.org/rss/1.0/spec">RSS</a>), multimedia metadata (<a
|
|
href="http://dublincore.org/">dublin core</a>, <a
|
|
href="http://musicbrainz.org/MM/">musicbrainz</a>) etc.</p>
|
|
|
|
<p>The iCalendar specification is fairly large, with 142 sections and a
|
|
number of complex interactions. The widely available software seems to cover
|
|
much of the useful functionality, but not every aspect of the specification;
|
|
for example, we have not seen tool support for <a
|
|
href="http://www.w3.org/2002/12/cal/rfc2445#sec4.8.5.2">exception rules</a>. Meanwhile, at the workshop, we
|
|
did have a number of actual iCalendar data files, representing real-world
|
|
events, that had been converted to RDF either manually or with scripts. The
|
|
resulting RDF/XML analogs served useful purposes to at least some of the
|
|
participants and seemed to be correct, by inspection, to all present. This
|
|
provided critical mass to begin maintaining a test suite.</p>
|
|
|
|
<div class="footnotes">
|
|
<dl>
|
|
<dt id="std-note">st</dt>
|
|
<dd>an <a href="http://www.ietf.org/">IETF</a> Proposed Standard, to be
|
|
exact. The IETF Calendaring and Scheduling Standards Simplification (<a
|
|
href="http://www.ietf.org/html.charters/calsify-charter.html">calsify</a>)
|
|
working group is chartered to "Advance the Calendaring and Scheduling
|
|
standards to Draft Standard," among other things.</dd>
|
|
</dl>
|
|
</div>
|
|
</div>
|
|
|
|
<div>
|
|
<h2 id="Collaborat">2. Collaboration challenges and rewards</h2>
|
|
|
|
<p>A particularly rewarding aspect of this collaboration is exploring
|
|
language and culture boundaries. Even though there is a six hour time
|
|
gap between Chicago and London, office hours overlap regularly, and
|
|
while the difference in dialect and etiquette is often entertaining,
|
|
it is rarely an obstacle to understanding. Our colleagues from Japan
|
|
are much more able to converse in English than we are in
|
|
Japanese. Even so, without the benefit of non-verbal clues, remote
|
|
conversations are particularly challenging. Email offers the chance to
|
|
read and compse at your own pace, but the timezone gaps between
|
|
America, Europe, and Asia effectively impose a 24 hour round-trip time
|
|
that is a real barrier to conversation. Internet Relay Chat (IRC)
|
|
allows near-real-time feedback and clarification as well as the
|
|
clarity of written text and a chance to reflect at least a few minutes
|
|
to digest one message and compose another, but only if all parties can
|
|
devote their attention at the same time.</p>
|
|
|
|
<p>We use an archived mailing list, <code>www-rdf-calendar@w3.org</code>, as
|
|
the <q>forum of record,</q> with any significant work that happens by chance
|
|
in IRC reported there after the fact. We also conduct a form of meeting over
|
|
IRC, called with advanced notice of a week or so, where some conscious effort
|
|
is given to agenda management, due process for decision making, follow-up on
|
|
actions, and the like. We have given the name <a
|
|
href="http://esw.w3.org/topic/ScheduledTopicChat">ScheduledTopicChat</a> to
|
|
this collaboration pattern. <a
|
|
href="http://esw.w3.org/topic/RdfCalendarMeetings">RdfCalendarMeetings</a>
|
|
serves as an index of meeting records.</p>
|
|
</div>
|
|
|
|
<div>
|
|
<h2 id="exsim">3. A simple example</h2>
|
|
|
|
<p>At a glance, converting iCalendar data to RDF is quite straightforward; in
|
|
iCalendar terms, an event is a <a
|
|
href="http://www.w3.org/2002/12/cal/rfc2445#sec4.6">component</a> with
|
|
various <a
|
|
href="http://www.w3.org/2002/12/cal/rfc2445#sec4.5">properties</a>:</p>
|
|
<pre>BEGIN:VEVENT
|
|
<span xml:lang="en" lang="en">UID:20020630T230445Z-3895-69-1-7@jammer</span>
|
|
<span xml:lang="en" lang="en">DTSTART;VALUE=DATE:20020703</span>
|
|
<span xml:lang="en" lang="en">DTEND;VALUE=DATE:20020706</span>
|
|
<span xml:lang="en" lang="en">SUMMARY:Scooby Conference</span>
|
|
<span xml:lang="en" lang="en">LOCATION:San Francisco</span>
|
|
<span xml:lang="en" lang="en">END:VEVENT</span></pre>
|
|
|
|
<p>and RDF/XML has analagous class and property constructs:</p>
|
|
<pre> <Vevent>
|
|
<uid>20020630T230445Z-3895-69-1-7@jammer</uid>
|
|
<dtstart>2002-07-03</dtstart>
|
|
<dtend>2002-07-06</date>
|
|
<summary>Scooby Conference</summary>
|
|
<location>San Francisco</location>
|
|
</Vevent></pre>
|
|
</div>
|
|
|
|
<div>
|
|
<h2 id="ns-gnd">4. Namespaces: grounding terms in URI space</h2>
|
|
|
|
<p>The terms <code>Vevent</code>, <code>uid</code>, etc. in the RDF/XML
|
|
example above are actually abbreviations. The <code>Vevent</code> element is
|
|
dominated by an element with namespace declarations:</p>
|
|
<pre><rdf:RDF
|
|
xmlns="http://www.w3.org/2002/12/cal#">
|
|
…
|
|
<Vevent>
|
|
<uid>20020630T230445Z-3895-69-1-7@jammer</uid>
|
|
<dtstart>2002-07-03</dtstart>
|
|
<dtend>2002-07-06</date>
|
|
<summary>Scooby Conference</summary>
|
|
<location>San Francisco</location>
|
|
</Vevent>
|
|
…
|
|
</rdf:RDF>
|
|
</pre>
|
|
|
|
<p>The result is that the element name <code>Vevent</code> is short for a
|
|
full URI <code>http://www.w3.org/2002/12/cal#Vevent</code>.</p>
|
|
</div>
|
|
|
|
<div>
|
|
<h2 id="comp">5. Calendar objects, components and files</h2>
|
|
|
|
<p>iCalendar data typically consists of a <a
|
|
href="http://www.w3.org/2002/12/cal/rfc2445#sec4.6"><code>CALENDAR</code>
|
|
component</a> with <code><a
|
|
href="http://www.w3.org/2002/12/cal/rfc2445#Vevent">VEVENT</a></code>
|
|
components and such inside it. An initial design identified the calendar
|
|
object with the RDF/XML document ala</p>
|
|
<pre> <Vcalendar rdf:about="">
|
|
…
|
|
</Vcalendar></pre>
|
|
|
|
<p>i.e. "this document is a Vcalendar with … ." But we ran into <a
|
|
href="http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Jan/0009.html">a
|
|
case of iCalendar data with more than one calendar in a file</a>. There was
|
|
some discrepancy among implementations as to whether this was good data;
|
|
mozilla did not seem to accept it, but this was reported as a bug<a
|
|
href="http://bugzilla.mozilla.org/show_bug.cgi?id=179985"><sup>#179985</sup></a>
|
|
and indeed, section <a
|
|
href="http://www.w3.org/2002/12/cal/rfc2445#sec4.4">4.4 iCalendar Object</a>
|
|
says</p>
|
|
|
|
<blockquote>
|
|
<p>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.</p>
|
|
</blockquote>
|
|
|
|
<p>So we decided<sup><a
|
|
href="http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Feb/0008.html">2003-02-12</a></sup>
|
|
to drop <code>rdf:about=""</code> from our icalendar<->RDF mapping.</p>
|
|
|
|
<p>iCalendar syntax has no name for the relationship between an outer
|
|
component and an inner component; it just uses the position in the syntax to
|
|
express the relationship. Syntactic position in RDF only tells the "part of
|
|
speech," i.e. subject, predicate, or object of a relationship, so we needed a
|
|
name for this relationship. We decided<a
|
|
href="http://rdfig.xmlhack.com/2003/02/12/2003-02-12.html#a1045063138.593306"><sup>2003-02-12</sup></a>
|
|
to use ical:component to relate calendars to events.</p>
|
|
|
|
<p>We have explored using the iCalendar uid property to make URIs for event
|
|
components<sup><a
|
|
href="http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Aug/0001.html">2003-08-19</a></sup>.
|
|
It's not clear whether events in separate files bearing the same uid should
|
|
be considered identical or merely different views of the same event. For
|
|
example, if they are identical, they have the same alarms. One approach that
|
|
seems to work well is to use the uid as a fragment identifier rather than as
|
|
a full URI.</p>
|
|
</div>
|
|
|
|
<h2 id="L10136">6. Capitalization and naming conventions</h2>
|
|
|
|
<p>While these examples suggest that the mapping is straightforward, they
|
|
also demonstrate one of the early issues: capitalization. In iCalendar,
|
|
component and property names are case insensitive and conventionally written
|
|
in all caps. But due to internationalization and simplicity considerations,
|
|
XML names and URIs are case sensitive, and RDF class and property names
|
|
inherit constraints from XML and URIs. In addition, the established
|
|
convention is that RDF class names are capitalized and RDF property names
|
|
begin with a lower case letter, and both use camelCase to join words.</p>
|
|
|
|
<p>The first attempts to convert iCalendar data to RDF were perl scripts of a
|
|
hundred lines or so that just manipulated the punctuation. But this approach
|
|
breaks down when the punctuation of a property depends on the name of the
|
|
property<sup><a href="#prop-type-note">p</a></sup>. Soon it became clear that
|
|
there were details beyond capitalization that varied from property type to
|
|
property type; the conversion process needed information from a schema.</p>
|
|
|
|
<div class="footnotes">
|
|
<dl>
|
|
<dt id="prop-type-note">p</dt>
|
|
<dd>or more precisely: on the value type of the property. Each property
|
|
type has a default value type; for example, <a
|
|
href="http://www.w3.org/2002/12/cal/rfc2445#dtstart">DTSTART</a>
|
|
defaults to <a
|
|
href="http://www.w3.org/2002/12/cal/rfc2445#Value_DATE-TIME">DATE-TIME</a>.
|
|
But a property parameter can be used to set the value type of an
|
|
individual property; for example:
|
|
<code>DTSTART;VALUE=DATE:19960401</code> .</dd>
|
|
</dl>
|
|
</div>
|
|
|
|
<div>
|
|
<h2 id="collab">7. Choosing a namespace policy</h2>
|
|
|
|
<p>Capitalization is one of many issues that had a number of efforts to
|
|
relate iCalendar and RDF (<a href="/2000/01/foo.html"><cite>A quick look at
|
|
iCalendar</cite></a> by Tim Berners-Lee in 2001, <a
|
|
href="http://ilrt.org/discovery/2001/06/schemas/ical-full/hybrid.rdf">hybrid.rdf</a>
|
|
by Miller and Arick in 2001, <a
|
|
href="/2000/10/swap/pim/ical2rdf.pl">ical2rdf.pl</a> by Connolly in 2002) had
|
|
explored independently. At the <a
|
|
href="/2001/sw/Europe/events/200210-cal/">workshop</a> 2002, we agreed to
|
|
work together on a shared RDF Schema, that is: a shared document in the Web
|
|
that provides definitions, of a sort, for a number of related terms. After
|
|
consideration of preserving the investment in each of the existing iCalendar
|
|
schemas, it seemed the data that referenced them might have been composed
|
|
with an expectation that those schemas would not change. We chose a new
|
|
namespace name, <tt>http://www.w3.org/2002/12/cal#</tt>.</p>
|
|
|
|
<p>The issues around managing changes to an RDF schema are similar to
|
|
managing changes in other documents: should you update the content in place,
|
|
or should you keep the old version there and put the new version at a
|
|
different place in the Web? We chose a process that is reasonably simple and
|
|
has proven to be quite robust and scalable: <strong>the schema is subject to
|
|
change, with notice and appeal</strong>; that is: all changes to the schema
|
|
are announced to the <code>www-rdf-calendar</code> mailing list; if anyone
|
|
objects within a week, the change is rolled back for further discussion.</p>
|
|
</div>
|
|
|
|
<div>
|
|
<h2 id="Generating"><a name="head-69f481dd239f19dd2a6c1315754fde19bfa92e84"
|
|
id="head-69f481dd239f19dd2a6c1315754fde19bfa92e84">8. Generating a schema
|
|
from examples</a></h2>
|
|
|
|
<p>The regular structure of the iCalendar specification, with components and
|
|
properties, suggests declaring corresponding RDF classes and properties in an
|
|
RDF schema should be straightforward. But an attempt to do it manually ( <a
|
|
href="http://ilrt.org/discovery/2001/06/schemas/ical-full/hybrid.rdf">hybrid.rdf</a>
|
|
by Miller and Arick in 2001) proved unwieldy.</p>
|
|
|
|
<p><a href="http://www.w3.org/DesignIssues/Notation3">Notation 3</a> is a
|
|
compact and readable alternative to RDF's XML syntax and an extension
|
|
to express logical rules. We explored using rules to
|
|
generate an RDF schema from our example data. For example, rules such as
|
|
</p>
|
|
<blockquote>
|
|
if something is related to something else by ?P, then ?P is a
|
|
Property</blockquote>
|
|
|
|
<p>can be expressed in Notation3 rule syntax:</p>
|
|
|
|
<pre>
|
|
{ [] ?P []. } => { ?P a r:Property }.
|
|
</pre>
|
|
|
|
<p>The <var>?P</var> syntax is for variables.
|
|
And in the same way:</p>
|
|
|
|
<blockquote>
|
|
if something is a ?C, then ?C is a Class
|
|
</blockquote>
|
|
|
|
<p>can be expressed in Notation 3 syntax as:</p>
|
|
|
|
<pre>
|
|
{ [] a ?C } => { ?C a s:Class }.
|
|
</pre>
|
|
|
|
<p>This approach worked to enumerate the classes and properties we were using
|
|
in our test data, but it did not provide important schema information such as
|
|
value types.</p>
|
|
|
|
<div>
|
|
<h2 id="Gleaning">9. Gleaning a schema from the specification text</h2>
|
|
|
|
<p>The iCalendar specification has a very regular structure for value types
|
|
and such:</p>
|
|
|
|
<blockquote cite="http://www.w3.org/2002/12/cal/rfc2445#sec4.8.2.4">
|
|
<pre>4.8.2.4 Date/Time Start
|
|
|
|
Property Name: DTSTART
|
|
|
|
Purpose: This property specifies when the calendar component begins.
|
|
|
|
Value Type: The default value type is DATE-TIME. The time value MUST
|
|
be one of the forms defined for the DATE-TIME value type. The value
|
|
type can be set to a DATE value type.</pre>
|
|
</blockquote>
|
|
|
|
<p>We converted this structured plain text to XHTML with semantic markup for
|
|
two reasons:</p>
|
|
<ol>
|
|
<li>to make it easier for people to navigate the structure of the
|
|
document</li>
|
|
<li>to facilitate generation of an RDF schema using XSLT</li>
|
|
</ol>
|
|
|
|
<p>A python program, <a
|
|
href="http://www.w3.org/2002/12/cal/slurpIcalSpec.py">slurpIcalSpec.py</a>,
|
|
produces XHTML including typed links from properties to value types:</p>
|
|
|
|
<blockquote>
|
|
<dl>
|
|
<dt id="dtstart">Property Name</dt>
|
|
<dd class="PropertyName"><pre> DTSTART</pre>
|
|
</dd>
|
|
<dt>Purpose</dt>
|
|
<dd class="Purpose"><pre> This property specifies when the calendar component begins.</pre>
|
|
</dd>
|
|
<dt>Value Type</dt>
|
|
</dl>
|
|
|
|
<p>The default value type is <a rel="default-value-type"
|
|
href="http://www.w3.org/2002/12/cal/rfc2445#Value_DATE-TIME">DATE-TIME</a></p>
|
|
|
|
|
|
<pre> . The time value MUST
|
|
be one of the forms defined for the <a rel="allowed-type" href="http://www.w3.org/2002/12/cal/rfc2445#Value_DATE">DATE</a>-TIME value type. The value
|
|
type can be set to a <a rel="allowed-type" href="http://www.w3.org/2002/12/cal/rfc2445#Value_DATE">DATE</a> value type.</pre>
|
|
</blockquote>
|
|
|
|
<p>The markup uses semantic class names and link relationships:</p>
|
|
|
|
<pre><h2 id="sec4.8.2.4">4.8.2.4 Date/Time Start</h2>
|
|
<dl>
|
|
<dt id="dtstart">Property Name</dt>
|
|
<dd class="PropertyName">
|
|
<pre> DTSTART
|
|
</pre>
|
|
</dd>
|
|
|
|
<dt>Purpose</dt>
|
|
<dd class="Purpose">
|
|
<pre>
|
|
This property specifies when the calendar component begins.
|
|
</pre>
|
|
</dd>
|
|
|
|
<dt>Value Type</dt>
|
|
<dd class="ValueType">The default value type is
|
|
<a rel="default-value-type"
|
|
href="#Value_DATE-TIME">DATE-TIME</a>
|
|
<pre>
|
|
. The time value MUST
|
|
be one of the forms defined for the
|
|
<a rel="allowed-type"
|
|
href="#Value_DATE">DATE</a>-TIME value type. The value
|
|
type can be set to a
|
|
<a rel="allowed-type"
|
|
href="#Value_DATE">DATE</a> value type.
|
|
</pre>
|
|
</dd>
|
|
|
|
</dl>
|
|
</pre>
|
|
|
|
<p>An XSLT transformation, <a
|
|
href="http://www.w3.org/2002/12/cal/webize2445.xsl">webize2445.xsl</a>, turns
|
|
this into RDF/OWL:</p>
|
|
<pre> <rdf:Description rdf:ID="dtstart">
|
|
<rdfs:label>DTSTART</rdfs:label>
|
|
<rdfs:comment>This property specifies when the calendar component begins.</rdfs:comment>
|
|
<rdfs:comment>
|
|
default value type: DATE-TIME</rdfs:comment>
|
|
<spec:valueType>DATE-TIME</spec:valueType>
|
|
<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#ObjectProperty"/>
|
|
<rdfs:range>
|
|
<owl:Class>
|
|
<owl:unionOf rdf:parseType="Collection">
|
|
<owl:Class rdf:about="#Value_DATE-TIME"/>
|
|
<owl:Class rdf:about="#Value_DATE"/>
|
|
<owl:Class rdf:about="#Value_DATE"/>
|
|
</owl:unionOf>
|
|
</owl:Class>
|
|
</rdfs:range></pre>
|
|
|
|
<p>This approach does not produce schema information for the
|
|
<code>component</code> property discussed <a href="#comp">above</a>, nor for
|
|
properties such as <code>interval</code> and <code>byday</code> used in
|
|
recurrence rules. Those should be added in due course.</p>
|
|
|
|
<p>The schema also currently lacks information about which properties are
|
|
functional or inverse-functional, which are needed for certain diff/sync
|
|
techniques<sup><a
|
|
href="http://lists.w3.org/Archives/Public/www-rdf-calendar/2004Mar/0016.html">2004-03-23</a></sup>.
|
|
Unfortunately, adding that information conflicts with certain OWL DL
|
|
restrictions, and makes it harder to use OWL DL checking tools with this
|
|
schema. This remains an open issue.</p>
|
|
|
|
<p>Another python program, <a
|
|
href="http://www.w3.org/2002/12/cal/compDecls.py">compDecls.py</a>, reads the
|
|
schema and prints it as a python data structure for use in our iCalendar to
|
|
RDF conversion utility<sup><a href="#comp-decl">td</a></sup>, <a
|
|
href="http://www.w3.org/2002/12/cal/fromIcal.py">fromIcal.py</a>:</p>
|
|
<pre> ('Vevent',
|
|
{"ATTACH": ('attach', 'URI', 0, None),
|
|
"CATEGORIES": ('categories', "TEXT", 0, None),
|
|
"SUMMARY": ('summary', "TEXT", 0, None),
|
|
"DTEND": ('dtend', 'DATE-TIME', 0, None),
|
|
"DTSTART": ('dtstart', 'DATE-TIME', 0, None),</pre>
|
|
|
|
<div class="footnotes">
|
|
<dl>
|
|
<dt id="comp-decl">td</dt>
|
|
<dd>Actually, we don't trust this conversion completely quite yet. The
|
|
schema is actually integrated into fromIcal.py in a test-driven manner:
|
|
not until a property is found in an actual test case is the relevant
|
|
declaration copied from the output of compDecls.py into the source code
|
|
of fromIcal.py, after careful inspection.</dd>
|
|
</dl>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div>
|
|
<h2 id="Extension">10. <a
|
|
name="head-7e86ceb92cba794b5aa2ce8f4735086f8075455e"
|
|
id="head-7e86ceb92cba794b5aa2ce8f4735086f8075455e"></a>Extension Tokens and
|
|
Product Identifiers</h2>
|
|
|
|
<p>The iCalendar syntax allows extension tokens in a number of places.
|
|
Ideally, we would like to ground these extension tokens in URI space as well,
|
|
but none of the approaches we have tried is completely satisfactory.</p>
|
|
|
|
<p>One approach was to specify a namespace for x- tokens on the command line,
|
|
at conversion time. The drawbacks of this approach are</p>
|
|
<ol>
|
|
<li>It is limited to one extension namespace. We have not explored in
|
|
detail any iCalendar data with extension tokens from more than one
|
|
source, but it is possible, at least in theory.</li>
|
|
<li>The user must somehow know the URI for the extensions in the file. RDF
|
|
schemas for these extensions are not widely deployed, so users would be
|
|
left with the problem of publishing them in many cases.</li>
|
|
</ol>
|
|
|
|
<p>iCalendar data is labelled with a product ID that serves a similar role to
|
|
an XML namespace name, though it is not expressed as a URI. We decided<sup><a
|
|
href="http://rdfig.xmlhack.com/2003/02/26/2003-02-26.html#a1046279142.860278">2003-02-26</a></sup>
|
|
to institute an ical product registry. When we found some extensions used by
|
|
some product, we would publish a schema for those extensions using a URI
|
|
starting with '<a
|
|
href="http://www.w3.org/2002/12/cal/prod/">http://www.w3.org/2002/12/cal/prod/</a>'
|
|
followed by a function of the product id.</p>
|
|
|
|
<p>The drawback of this approach is that it does not seem to be worth the
|
|
trouble. In practice, we seem to be more content to just disregard the
|
|
extended properties. Handling extensions remains an outstanding issue in our
|
|
test suite<a
|
|
href="http://ilrt.org/discovery/chatlogs/rdfig/2003-08-20.html#T15-43-10"><sup>2003-08-20</sup></a>.</p>
|
|
|
|
<p>Now that we have explored the schema and extension tokens, let's look at
|
|
the calendar data itself.</p>
|
|
</div>
|
|
|
|
<div>
|
|
<h2 id="L21805">11. Shop hours, recurring events and timezones</h2>
|
|
|
|
<p>Consider the case of a shop with regular hours. Contemporary directory
|
|
services provide telephone numbers and street addresses, complete with
|
|
automated driving directions. But you still have to pick up the phone and
|
|
call them to find out when they're open. Typical shop hours can be expressed
|
|
using recurring events in iCalendar. The <a
|
|
href="http://www.w3.org/2002/12/cal/test/bus-hrs.rdf">bus-hrs.rdf</a> test
|
|
expresses "Open 11:30a-11:30p Wed-Sun; Open Tue 4-11p" in RDF<sup><a
|
|
href="#ttl">ttl</a></sup>:</p>
|
|
<pre>@prefix : <http://www.w3.org/2002/12/cal/icaltzd#> .
|
|
@prefix NY: <http://www.w3.org/2002/12/cal/tzd/America/New_York#> .
|
|
<#20030314T052745Z-25601-69-1-8@dirk> a :Vevent;
|
|
:class "PUBLIC";
|
|
:dtend "2003-03-12T23:00:00"^^NY:tz;
|
|
:dtstart "2003-03-12T11:30:00"^^NY:tz;
|
|
:rrule [
|
|
:byday "SU,WE,TH,FR,SA";
|
|
:freq "WEEKLY";
|
|
:interval "1" ];
|
|
:summary "Open 11:30a-11:30p Wed-Sun".
|
|
<#20030314T052656Z-25601-69-1-0@dirk> a :Vevent;
|
|
:class "PUBLIC";
|
|
:dtend "2003-03-11T23:00:00"^^NY:tz;
|
|
:dtstart "2003-03-11T16:00:00"^^NY:tz;
|
|
:rrule [
|
|
:byday "TU";
|
|
:freq "WEEKLY";
|
|
:interval "1" ];
|
|
:summary "Open Tue 4-11p".</pre>
|
|
|
|
<p>There is a question of whether timezone rules should be given by reference
|
|
or by copy. Some data from early releases of Apple's iCal application lacked
|
|
explicit VTIMEZONE components, but the specification is clear that they are
|
|
required and this was acknowledged as a bug in Apple's iCal<sup><a
|
|
href="http://lists.w3.org/Archives/Public/www-rdf-calendar/2003Mar/0011.html">2003-03-12</a></sup>
|
|
and has since been fixed. So the bus-hrs.rdf file includes timezone rules:</p>
|
|
<pre> NY:tz a :Vtimezone;
|
|
:daylight [
|
|
:dtstart "1970-04-05T02:00:00"^^:dateTime;
|
|
:rrule [
|
|
:byday "1SU";
|
|
:bymonth "4";
|
|
:freq "YEARLY";
|
|
:interval "1" ];
|
|
:tzname "EDT";
|
|
:tzoffsetfrom "-0500";
|
|
:tzoffsetto "-0400" ];
|
|
:standard [
|
|
:dtstart "1970-10-25T02:00:00"^^:dateTime;
|
|
:rrule [
|
|
:byday "-1SU";
|
|
:bymonth "10";
|
|
:freq "YEARLY";
|
|
:interval "1" ];
|
|
:tzname "EST";
|
|
:tzoffsetfrom "-0400";
|
|
:tzoffsetto "-0500" ];
|
|
:tzid "/softwarestudio.org/Olson_20011030_5/America/New_York";
|
|
x-lic:location "America/New_York" .</pre>
|
|
|
|
<p>While those rules are an accurate model of the timezone in New York at
|
|
least as far back as 1970, the Energy Policy Act of 2005 is intended to
|
|
change them in 2006. While the Olson database is likely to reflect these
|
|
changes in due course, the copies in all the iCalendar data out there will
|
|
fail to accurately represent the timezone rules for New York.</p>
|
|
|
|
<p>One approach, exemplified by the <a
|
|
href="http://www.microformats.org/wiki/datetime-design-pattern">datetime
|
|
design pattern</a> in the microformats community, is to not use iCalendar
|
|
timezones, but only UTC dates<sup><a href="#delt">delt</a></sup>.</p>
|
|
|
|
<p>Another approach is to put the timezone rules in the Web, establish change
|
|
control policies with some minimum notice, and pass timezones around by
|
|
reference. As a step in this direction, we have published each entry in a
|
|
version of the Olsen database in our RDF Calendar workspace. For example,
|
|
<code>NY:tz</code>, i.e.
|
|
<code>http://www.w3.org/2002/12/cal/tzd/America/New_York#tz</code>. We are
|
|
considering some way to connect this data to the relevant political
|
|
decision-making processes. Ultimately, it would be best if the respective
|
|
policitcal organizations published the data by themselves.</p>
|
|
|
|
<p>There are a few other issues to note from the example above, some of which
|
|
are resolved:</p>
|
|
<ul>
|
|
<li>We punctuate dates with hyphens, following XML Schema datatypes, rather
|
|
than using iCalendar syntax exactly.</li>
|
|
<li>The interval is given explicitly, even though it is the default value,
|
|
"1". Defaults are a form of <a
|
|
href="http://esw.w3.org/topic/ClosedWorldAssumptions">closed world
|
|
assumption</a>; it's simpler to avoid them in Semantic Web data<sup><a
|
|
href="http://ilrt.org/discovery/chatlogs/rdfig/2003-02-12.html">2003-02-12</a></sup>.</li>
|
|
</ul>
|
|
|
|
<p>and some of which are not:</p>
|
|
<ul>
|
|
<li>Note that <code>NY:tz</code> timezone is used as a datatype. Earlier,
|
|
we used separate properties for time and timezone, which is initially
|
|
appealing but problematic for reasons that are detailed in the <a
|
|
href="http://esw.w3.org/topic/InterpretationProperties">InterpretationProperties</a>
|
|
pattern.
|
|
<ul>
|
|
<li>Objections were raised when this change was made to the original
|
|
<code>…2002/12/cal/ical#</code> schema. This design is using a
|
|
somewhat experimental<a
|
|
href="http://lists.w3.org/Archives/Public/www-rdf-calendar/2005Mar/0015.html"><sup>2005-03-30</sup></a>
|
|
namespace name, <code>…2002/12/cal/icaltzd#</code>.</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>We hope to find a consensus with a number of parties on issues around
|
|
timezones and recurring events:</p>
|
|
<ul>
|
|
<li>The daml-time work looks promising; we have some outstanding
|
|
questions<sup><a
|
|
href="http://lists.w3.org/Archives/Public/www-rdf-calendar/2005Feb/0009">2005-02-18</a></sup>
|
|
for them.</li>
|
|
<li>The IETF <a
|
|
href="http://www.ietf.org/html.charters/calsify-charter.html">calsify</a>
|
|
WG is reconsidering recurrence rules, with input such as the <a
|
|
href="http://lists.w3.org/Archives/Public/www-rdf-calendar/2005Jul/0003.html">Calconnect
|
|
Recurrence Questionnaire</a>.</li>
|
|
</ul>
|
|
</div>
|
|
<dl class="footnotes">
|
|
<dt id="ttl">ttl</dt>
|
|
<dd>here we display the data using the <a
|
|
href="http://www.dajobe.org/2004/01/turtle/">turtle</a>
|
|
syntax for RDF. The <a
|
|
href="http://www.w3.org/2000/10/swap/Primer.html">N3 primer</a> is a
|
|
gentle introduction to the turtle subset of N3.</dd>
|
|
<dt><span id="delt">delt</span></dt>
|
|
<dd>with some syntactic support for offsets like -0400</dd>
|
|
</dl>
|
|
|
|
<h2 id="Locations">12. Events, places, names, and coordinates</h2>
|
|
|
|
<p>The iCalendar specification includes two features related to places. The
|
|
<a href="http://www.w3.org/2002/12/cal/rfc2445#sec4.8.1.7">location</a>
|
|
property "… defines the intended venue for the activity defined by a
|
|
calendar component." That is, it gives a name of the place where the event
|
|
occurs. For example:</p>
|
|
<pre> <#20020630T230445Z-3895-69-1-7@jammer> a :Vevent;
|
|
:summary "X3 Conference";
|
|
:location "San Francisco";
|
|
:description "can't wait!\n";
|
|
:dtstart "2002-07-03"^^XML:date;
|
|
:dtend "2002-07-06"^^XML:date;
|
|
:uid "20020630T230445Z-3895-69-1-7@jammer" .</pre>
|
|
|
|
<p>The <a href="http://www.w3.org/2002/12/cal/rfc2445#geo">geo</a> property
|
|
takes a list of 2 floats: latitude and longitude. For example:</p>
|
|
<pre> geo:CDC474D4-1393-11D7-9A2C-000393914268 a :Vevent;
|
|
:summary "meeting 23";
|
|
:geo (
|
|
40.442673
|
|
-79.945815 );
|
|
:dtstart "2003-01-08T13:00:00"^^New:tz;
|
|
:dtend "2003-01-08T14:00:00"^^New:tz .</pre>
|
|
|
|
<p>The relationship of these properties to the <a
|
|
href="http://www.w3.org/2003/01/geo/">Basic Geo (WGS84 lat/long)
|
|
Vocabulary</a> also in development in the Semantic Web Interest Group has
|
|
been discussed, but not conclusively. Note that <code>location</code> relates
|
|
an event to the <em>name</em> of a place, not the place itself; likewise,
|
|
<code>geo</code> relates an event to a pair of coordinates, not a place. If
|
|
we take <code>:place</code> to be a property that relates an event to a place
|
|
where it occurs<sup><a href="#cyc">cyc</a></sup>, It seems reasonable to
|
|
relate them using rules such as:</p>
|
|
<pre>{ ?E cal:geo (?LAT ?LONG) }
|
|
<=> { ?E :place [ geo:lat ?LAT; geo:long ?LONG ] }.
|
|
{ ?E cal:location ?TXT }
|
|
<=> { ?E :place [ rdfs:label ?TXT ] }.</pre>
|
|
<dl class="footnotes">
|
|
<dt id="cyc">cyc</dt>
|
|
<dd>compare <a
|
|
href="http://www.cyc.com/cycdoc/vocab/actor-vocab.html#eventOccursAt">#$eventOccursAt</a>
|
|
in the <a href="http://www.cyc.com/cycdoc/vocab/vocab-toc.html">cyc
|
|
vocabulary</a></dd>
|
|
</dl>
|
|
|
|
<div>
|
|
<h2 id="testdr">13. Using RDF graph comparison for round-trip testing</h2>
|
|
|
|
<p>The vehicle for our exploration of schema and data issues is a test suite.
|
|
At this point, we have a schema supported by a useful, if not complete,
|
|
collection of <a href="http://www.w3.org/2002/12/cal/#dev">tests and
|
|
conversion tools</a>:</p>
|
|
<ul>
|
|
<li>Each test consists of a <code>$testcase.ics</code> file that is judged
|
|
to be a correct iCalendar file (i.e. it conforms to RFC 2445 and one or
|
|
more popular iCalendar tool consumes it correctly and/or allows the user
|
|
to produce it) and a corresponding <code>$testcase.rdf</code> file that
|
|
is judged to agree. For example, <code>cal01.ics</code> and
|
|
<code>cal01.rdf</code> are one test case.</li>
|
|
<li>An iCalendar to RDF conversion tool can be tested as follows:
|
|
<ol>
|
|
<li>Use the tool under test to convert <code>$testcase.ics</code> to a
|
|
temporary <code>$testcase-actual.rdf</code> file.</li>
|
|
<li>Compare the actual results with <code>$testcase.rdf</code>, the
|
|
expected results, using an RDF graph comparison tool.</li>
|
|
</ol>
|
|
</li>
|
|
<li>A tool to convert to iCalendar from RDF can be tested with respect to a
|
|
correct tool that goes the other way:
|
|
<ol>
|
|
<li>Use the tool under test to convert <code>$testcase.rdf</code> to
|
|
<code>$testcase-temp.ics</code>.</li>
|
|
<li>Use the known-good tool to convert <code>$testcase-temp.ics</code>
|
|
to <code>$testcase-actual.rdf</code>.</li>
|
|
<li>Compare <code>$test-case-actual.rdf</code> to the expected results,
|
|
<code>$testcase.rdf</code>, using an RDF graph comparison tool.</li>
|
|
</ol>
|
|
</li>
|
|
<li>The schema can be checked against the test data to see that…
|
|
<ul>
|
|
<li>each class and property in the schema is used in one or more test
|
|
cases,</li>
|
|
<li>each class or property used in a test case is declared in the
|
|
schema, and</li>
|
|
<li>each <code>$testcase.rdf</code> is logically consistent with the
|
|
schema.</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>The following table shows, for each component and property, the test case
|
|
files that use that property on that type of component:</p>
|
|
|
|
<table border="1">
|
|
<caption>Index: Test Coverage</caption>
|
|
<tbody>
|
|
<tr>
|
|
<th>Component</th>
|
|
<th>Property</th>
|
|
<th>Value Type</th>
|
|
<th>$testcase.rdf</th>
|
|
</tr>
|
|
<tr>
|
|
<td>VALARM</td>
|
|
<td>ACTION</td>
|
|
<td>TEXT</td>
|
|
<td><tt>20030115mtg.rdf</tt>, <tt>20030122mtg.rdf</tt>,
|
|
<tt>TestTermin.rdf</tt>, <tt>cal01.rdf</tt>, <tt>cal02.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VALARM</td>
|
|
<td>DESCRIPTION</td>
|
|
<td>TEXT</td>
|
|
<td><tt>TestTermin.rdf</tt>, <tt>cal01.rdf</tt>,
|
|
<tt>cal02.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VALARM</td>
|
|
<td>TRIGGER</td>
|
|
<td>DURATION</td>
|
|
<td><tt>20030115mtg.rdf</tt>, <tt>20030122mtg.rdf</tt>,
|
|
<tt>TestTermin.rdf</tt>, <tt>cal01.rdf</tt>, <tt>cal02.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VEVENT</td>
|
|
<td>ATTENDEE</td>
|
|
<td>CAL-ADDRESS</td>
|
|
<td><tt>20030115mtg.rdf</tt>, <tt>20030122mtg.rdf</tt>,
|
|
<tt>cal01.rdf</tt>, <tt>cal02.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VEVENT</td>
|
|
<td>CATEGORIES</td>
|
|
<td>TEXT</td>
|
|
<td><tt>cal01.rdf</tt>, <tt>cal02.rdf</tt>, <tt>tag-bug.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VEVENT</td>
|
|
<td>CLASS</td>
|
|
<td>TEXT</td>
|
|
<td><tt>MozexportAsCalendar.rdf</tt>, <tt>TestTermin.rdf</tt>,
|
|
<tt>bus-hrs.rdf</tt>, <tt>cal01.rdf</tt>, <tt>cal02.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VEVENT</td>
|
|
<td>COMMENT</td>
|
|
<td>TEXT</td>
|
|
<td><tt>gkexample.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VEVENT</td>
|
|
<td>DESCRIPTION</td>
|
|
<td>TEXT</td>
|
|
<td><tt>20030205mtg.rdf</tt>, <tt>TestTermin.rdf</tt>,
|
|
<tt>cal01.rdf</tt>, <tt>cal02.rdf</tt>, <tt>tag-bug.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VEVENT</td>
|
|
<td>DTEND</td>
|
|
<td>DATE-TIME</td>
|
|
<td><tt>20030122mtg.rdf</tt>, <tt>20030205mtg.rdf</tt>,
|
|
<tt>20030212mtg.rdf</tt>, <tt>20030226mtg.rdf</tt>,
|
|
<tt>20030312mtg.rdf</tt>, <tt>20030326mtg.rdf</tt>,
|
|
<tt>20030409mtg.rdf</tt>, <tt>20030410querymtg.rdf</tt>,
|
|
<tt>20030416geomtg.rdf</tt>, <tt>20030423mtg.rdf</tt>,
|
|
<tt>Chiefs.rdf</tt>, <tt>MozexportAsCalendar.rdf</tt>,
|
|
<tt>TestTermin.rdf</tt>, <tt>bus-hrs.rdf</tt>, <tt>cal01.rdf</tt>,
|
|
<tt>cal02.rdf</tt>, <tt>gkexample.rdf</tt>, <tt>mtg.rdf</tt>,
|
|
<tt>openingHours.rdf</tt>, <tt>querymeetings.rdf</tt>,
|
|
<tt>tag-bug.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VEVENT</td>
|
|
<td>DTSTAMP</td>
|
|
<td>DATE-TIME</td>
|
|
<td><tt>20030115mtg.rdf</tt>, <tt>20030122mtg.rdf</tt>,
|
|
<tt>20030205mtg.rdf</tt>, <tt>20030212mtg.rdf</tt>,
|
|
<tt>20030226mtg.rdf</tt>, <tt>20030312mtg.rdf</tt>,
|
|
<tt>20030326mtg.rdf</tt>, <tt>20030409mtg.rdf</tt>,
|
|
<tt>20030410querymtg.rdf</tt>, <tt>20030416geomtg.rdf</tt>,
|
|
<tt>20030423mtg.rdf</tt>, <tt>Chiefs.rdf</tt>,
|
|
<tt>MozexportAsCalendar.rdf</tt>, <tt>TestTermin.rdf</tt>,
|
|
<tt>bus-hrs.rdf</tt>, <tt>cal01.rdf</tt>, <tt>cal02.rdf</tt>,
|
|
<tt>mtg.rdf</tt>, <tt>querymeetings.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VEVENT</td>
|
|
<td>DTSTART</td>
|
|
<td>DATE-TIME</td>
|
|
<td><tt>20030115mtg.rdf</tt>, <tt>20030122mtg.rdf</tt>,
|
|
<tt>20030205mtg.rdf</tt>, <tt>20030212mtg.rdf</tt>,
|
|
<tt>20030226mtg.rdf</tt>, <tt>20030312mtg.rdf</tt>,
|
|
<tt>20030326mtg.rdf</tt>, <tt>20030409mtg.rdf</tt>,
|
|
<tt>20030410querymtg.rdf</tt>, <tt>20030416geomtg.rdf</tt>,
|
|
<tt>20030423mtg.rdf</tt>, <tt>Chiefs.rdf</tt>,
|
|
<tt>MozexportAsCalendar.rdf</tt>, <tt>TestTermin.rdf</tt>,
|
|
<tt>bus-hrs.rdf</tt>, <tt>cal01.rdf</tt>, <tt>cal02.rdf</tt>,
|
|
<tt>gkexample.rdf</tt>, <tt>mtg.rdf</tt>, <tt>openingHours.rdf</tt>,
|
|
<tt>querymeetings.rdf</tt>, <tt>tag-bug.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VEVENT</td>
|
|
<td>DURATION</td>
|
|
<td>DURATION</td>
|
|
<td><tt>20030115mtg.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VEVENT</td>
|
|
<td>EXDATE</td>
|
|
<td>DATE-TIME</td>
|
|
<td><tt>tag-bug.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VEVENT</td>
|
|
<td>LAST-MODIFIED</td>
|
|
<td>DATE-TIME</td>
|
|
<td><tt>bus-hrs.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VEVENT</td>
|
|
<td>LOCATION</td>
|
|
<td>TEXT</td>
|
|
<td><tt>TestTermin.rdf</tt>, <tt>cal01.rdf</tt>,
|
|
<tt>cal02.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VEVENT</td>
|
|
<td>ORGANIZER</td>
|
|
<td>CAL-ADDRESS</td>
|
|
<td><tt>20030115mtg.rdf</tt>, <tt>20030122mtg.rdf</tt>,
|
|
<tt>TestTermin.rdf</tt>, <tt>cal01.rdf</tt>, <tt>cal02.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VEVENT</td>
|
|
<td>PRIORITY</td>
|
|
<td>INTEGER</td>
|
|
<td><tt>TestTermin.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VEVENT</td>
|
|
<td>RRULE</td>
|
|
<td>RECUR</td>
|
|
<td><tt>bus-hrs.rdf</tt>, <tt>cal01.rdf</tt>, <tt>cal02.rdf</tt>,
|
|
<tt>gkexample.rdf</tt>, <tt>openingHours.rdf</tt>,
|
|
<tt>tag-bug.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VEVENT</td>
|
|
<td>SEQUENCE</td>
|
|
<td>integer</td>
|
|
<td><tt>20030115mtg.rdf</tt>, <tt>20030122mtg.rdf</tt>,
|
|
<tt>20030205mtg.rdf</tt>, <tt>20030212mtg.rdf</tt>,
|
|
<tt>20030226mtg.rdf</tt>, <tt>20030312mtg.rdf</tt>,
|
|
<tt>20030326mtg.rdf</tt>, <tt>20030409mtg.rdf</tt>,
|
|
<tt>20030410querymtg.rdf</tt>, <tt>20030416geomtg.rdf</tt>,
|
|
<tt>20030423mtg.rdf</tt>, <tt>TestTermin.rdf</tt>,
|
|
<tt>bus-hrs.rdf</tt>, <tt>cal01.rdf</tt>, <tt>cal02.rdf</tt>,
|
|
<tt>mtg.rdf</tt>, <tt>querymeetings.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VEVENT</td>
|
|
<td>SUMMARY</td>
|
|
<td>TEXT</td>
|
|
<td><tt>20030115mtg.rdf</tt>, <tt>20030122mtg.rdf</tt>,
|
|
<tt>20030205mtg.rdf</tt>, <tt>20030212mtg.rdf</tt>,
|
|
<tt>20030226mtg.rdf</tt>, <tt>20030312mtg.rdf</tt>,
|
|
<tt>20030326mtg.rdf</tt>, <tt>20030409mtg.rdf</tt>,
|
|
<tt>20030410querymtg.rdf</tt>, <tt>20030416geomtg.rdf</tt>,
|
|
<tt>20030423mtg.rdf</tt>, <tt>Chiefs.rdf</tt>,
|
|
<tt>MozexportAsCalendar.rdf</tt>, <tt>TestTermin.rdf</tt>,
|
|
<tt>bus-hrs.rdf</tt>, <tt>cal01.rdf</tt>, <tt>cal02.rdf</tt>,
|
|
<tt>mtg.rdf</tt>, <tt>querymeetings.rdf</tt>,
|
|
<tt>tag-bug.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VEVENT</td>
|
|
<td>TRANSP</td>
|
|
<td>TEXT</td>
|
|
<td><tt>TestTermin.rdf</tt>, <tt>bus-hrs.rdf</tt>, <tt>cal01.rdf</tt>,
|
|
<tt>cal02.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VEVENT</td>
|
|
<td>UID</td>
|
|
<td>TEXT</td>
|
|
<td><tt>20030115mtg.rdf</tt>, <tt>20030122mtg.rdf</tt>,
|
|
<tt>20030205mtg.rdf</tt>, <tt>20030212mtg.rdf</tt>,
|
|
<tt>20030226mtg.rdf</tt>, <tt>20030312mtg.rdf</tt>,
|
|
<tt>20030326mtg.rdf</tt>, <tt>20030409mtg.rdf</tt>,
|
|
<tt>20030410querymtg.rdf</tt>, <tt>20030416geomtg.rdf</tt>,
|
|
<tt>20030423mtg.rdf</tt>, <tt>Chiefs.rdf</tt>,
|
|
<tt>MozexportAsCalendar.rdf</tt>, <tt>TestTermin.rdf</tt>,
|
|
<tt>bus-hrs.rdf</tt>, <tt>cal01.rdf</tt>, <tt>cal02.rdf</tt>,
|
|
<tt>mtg.rdf</tt>, <tt>querymeetings.rdf</tt>,
|
|
<tt>tag-bug.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VTIMEZONE</td>
|
|
<td>LAST-MODIFIED</td>
|
|
<td>DATE-TIME</td>
|
|
<td><tt>Todos1.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VTIMEZONE</td>
|
|
<td>TZID</td>
|
|
<td>TEXT</td>
|
|
<td><tt>20030115mtg.rdf</tt>, <tt>20030122mtg.rdf</tt>,
|
|
<tt>20030205mtg.rdf</tt>, <tt>20030212mtg.rdf</tt>,
|
|
<tt>20030226mtg.rdf</tt>, <tt>20030312mtg.rdf</tt>,
|
|
<tt>20030326mtg.rdf</tt>, <tt>20030409mtg.rdf</tt>,
|
|
<tt>20030410querymtg.rdf</tt>, <tt>20030416geomtg.rdf</tt>,
|
|
<tt>20030423mtg.rdf</tt>, <tt>Chiefs.rdf</tt>, <tt>Todos1.rdf</tt>,
|
|
<tt>bus-hrs.rdf</tt>, <tt>cal01.rdf</tt>, <tt>cal02.rdf</tt>,
|
|
<tt>mtg.rdf</tt>, <tt>querymeetings.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VTODO</td>
|
|
<td>COMPLETED</td>
|
|
<td>DATE-TIME</td>
|
|
<td><tt>Todos1.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VTODO</td>
|
|
<td>DTSTAMP</td>
|
|
<td>DATE-TIME</td>
|
|
<td><tt>Todos1.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VTODO</td>
|
|
<td>DTSTART</td>
|
|
<td>DATE-TIME</td>
|
|
<td><tt>Todos1.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VTODO</td>
|
|
<td>DUE</td>
|
|
<td>DATE-TIME</td>
|
|
<td><tt>Todos1.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VTODO</td>
|
|
<td>PRIORITY</td>
|
|
<td>INTEGER</td>
|
|
<td><tt>Todos1.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VTODO</td>
|
|
<td>SEQUENCE</td>
|
|
<td>integer</td>
|
|
<td><tt>Todos1.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VTODO</td>
|
|
<td>STATUS</td>
|
|
<td>TEXT</td>
|
|
<td><tt>Todos1.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VTODO</td>
|
|
<td>SUMMARY</td>
|
|
<td>TEXT</td>
|
|
<td><tt>Todos1.rdf</tt>,</td>
|
|
</tr>
|
|
<tr>
|
|
<td>VTODO</td>
|
|
<td>UID</td>
|
|
<td>TEXT</td>
|
|
<td><tt>Todos1.rdf</tt>,</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<div id="mixing">
|
|
|
|
<div id="other">
|
|
<h2 id="L1877">14. Related Work</h2>
|
|
|
|
<p>There are a number of related calendar data format projects.</p>
|
|
|
|
<h3 id="L1892">14.1. xCalendar</h3>
|
|
|
|
<p><a
|
|
href="http://ietfreport.isoc.org/idref/draft-hare-xcalendar/">XCalendar</a>
|
|
is a simple syntactic conversion of iCalendar to XML. For events with simple
|
|
attribute-value properties it produces results very similar to RDF case; the
|
|
differences are syntactic (capitalization) or have to do with the model RDF
|
|
imposes.</p>
|
|
|
|
<p>An XSLT transformation from xCalendar to iCalendar is provided.</p>
|
|
|
|
<p>We have considered a syntactic profile of RDF calendar that would meet the
|
|
same requirements, but we have not managed to develop a tool to produce this
|
|
profile given an arbitrary RDF calendar graph as input.</p>
|
|
|
|
<h3 id="L1901">14.2. RSS event module</h3>
|
|
|
|
<p><a href="http://web.resource.org/rss/1.0/modules/event/">RSS Events</a> is
|
|
a proposed module for RSS 1.0. It uses a simple vocabulary inspired by
|
|
iCalendar:</p>
|
|
<pre> <item rdf:about="http://conferences.oreilly.com/p2p/">
|
|
<title>The O'Reilly Peer-to-Peer and Web Services Conference</title>
|
|
<link>http://conferences.oreilly.com/p2p/</link>
|
|
<ev:type>conference</ev:type>
|
|
<ev:organizer>O'Reilly</ev:organizer>
|
|
<ev:location>Washington, DC</ev:location>
|
|
<ev:startdate>2001-09-18</ev:startdate>
|
|
<ev:enddate>2001-09-21</ev:enddate>
|
|
</item></pre>
|
|
|
|
<p>It uses the homepage of an event as the url for the description of the
|
|
event.</p>
|
|
</div>
|
|
|
|
<h2 id="conc1">15. Conclusions and future work</h2>
|
|
|
|
<p>While the RDF Calendar vocabulary is still a work-in-progress, it provides
|
|
anyone with RDF or XML tools a useful alternative to dealing with the
|
|
character-level syntax of iCalendar. Our test-driven approach to Semantic Web
|
|
vocabulary development has allowed us to manage changes as we explored and
|
|
resolved a variety of issues. The "subject to change with notice and appeal"
|
|
change policy for our schema seems to work well.</p>
|
|
|
|
<p>We have exploited the graph model of RDF in our round-trip testing work,
|
|
but explorations into comparisons, especially for the purpose of
|
|
synchronizing changes, are at an early stage. See <a
|
|
href="http://www.w3.org/DesignIssues/Diff.html"><cite>Delta: an ontology for
|
|
the distribution of differences between RDF graphs</cite></a> for one
|
|
approach.</p>
|
|
|
|
<p>We are still in relatively early stages of mixing calendar data with other
|
|
Semantic Web data. As an illustrative example, consider using the <a
|
|
href="http://xmlns.com/foaf/0.1/">FOAF</a> vocabulary to describe an attendee
|
|
of an event:</p>
|
|
<pre>[] a :Vevent ;
|
|
:attendee
|
|
[ a foaf:Person ;
|
|
:calAddress <mailto:me@example.com> ;
|
|
foaf:mbox <mailto:me@example.com> ;
|
|
foaf:name "My name"
|
|
] ;
|
|
:dtend "2002-06-30T10:30:00"^^NY:tz ;
|
|
:dtstart "2002-06-30T09:00:00"^^NY:tz ;
|
|
:summary "Tree Conference" .</pre>
|
|
|
|
<p>The iCalendar specification has some prohibitions against publishing email
|
|
addresses. This is one of many privacy considerations with calendar data.</p>
|
|
|
|
<p>Queries and rules to relate photos to events via metadata such as
|
|
date-taken is another promising area of work.</p>
|
|
|
|
<div>
|
|
<h3 id="L1879">15.1. hCalendar and microformats</h3>
|
|
|
|
<p><a href="http://microformats.org/wiki/hcalendar">hCalendar</a> is an
|
|
emerging microformat, i.e. a set of semantic XHTML markup conventions. It is
|
|
based on iCalendar. The approach to human-readability is interesting; for
|
|
example:</p>
|
|
<pre><abbr class="dtstart" title="2005-10-05">October 5</abbr></pre>
|
|
|
|
<p>We are working on a <a
|
|
href="http://www.w3.org/2002/12/cal/glean-hcal.xsl">glean-hcal.xsl</a>, a
|
|
transformation from hCalendar to RDF Calendar. Using hCalendar with <a
|
|
href="http://www.w3.org/2003/g/data-view">GRDDL</a> is particularly
|
|
promising, though it goes beyond the scope of this report.</p>
|
|
|
|
<p>Note that open source implementaitons of the following transformations are
|
|
available, either from the RDF Calendar workspace or projects nearby:</p>
|
|
|
|
<table border="1">
|
|
<caption>Conversions</caption>
|
|
<tbody>
|
|
<tr>
|
|
<td></td>
|
|
<th>from iCalendar</th>
|
|
<th>hCalendar</th>
|
|
<th>RDF Calendar</th>
|
|
</tr>
|
|
<tr>
|
|
<th>to iCalendar</th>
|
|
<td></td>
|
|
<td>X2V</td>
|
|
<td>toIcal.py</td>
|
|
</tr>
|
|
<tr>
|
|
<th>hCalendar</th>
|
|
<td></td>
|
|
<td></td>
|
|
<td></td>
|
|
</tr>
|
|
<tr>
|
|
<th>RDF Calendar</th>
|
|
<td>fromIcal.py</td>
|
|
<td><a
|
|
href="http://www.w3.org/2002/12/cal/glean-hcal.xsl">glean-hcal.xsl</a></td>
|
|
<td></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
</div>
|
|
|
|
<h2 id="Acknowledg">16. Acknowledgements</h2>
|
|
|
|
<p>We are greatful to Masahide Kanzaki for his <a
|
|
href="http://www.kanzaki.com/docs/sw/rdf-calendar.html">RDF calendar
|
|
service</a>, to Olivier Gutknecht and Paul Cowles for their commercial
|
|
product development perspective, and the collaborators in
|
|
www-rdf-calendar, including Julian Reschke, Doug Royer, Tim
|
|
Berners-Lee, Dave Thewlis, Karl Dubost, Charles McCathieNevile,
|
|
Michael Arick, Norman Walsh, Tim Hare, and Dan Brickley.</p>
|
|
|
|
<h2 id="L1962">17. References</h2>
|
|
<ul>
|
|
<li><a href="http://www.w3.org/2002/12/cal/">RDF Calendar workspace</a></li>
|
|
<li>Internet Calendaring and Scheduling Core Object Specification
|
|
(iCalendar) [<a href="http://www.w3.org/2002/12/cal/rfc2445">RFC2554</a>], Dawson and Stenerson,
|
|
November 1998</li>
|
|
<li>IETF Calendaring and Scheduling Standards Simplification (<a
|
|
href="http://www.ietf.org/html.charters/calsify-charter.html">calsify</a>)
|
|
working group</li>
|
|
<li>Resource Description Framework (<a
|
|
href="http://esw.w3.org/topic/RDF">RDF</a>). W3C Recommendations Feb
|
|
2004</li>
|
|
<li><a
|
|
href="http://www.w3.org/2001/sw/Europe/reports/dev_workshop_report_2/Overview.html">SWAD-Europe
|
|
Deliverable 3.7: Developer Workshop Report 2 - Semantic Web
|
|
calendaring</a>, Miller, Dec 2002</li>
|
|
<li>esw wiki topics: <a
|
|
href="http://esw.w3.org/topic/ScheduledTopicChat">ScheduledTopicChat</a>,
|
|
<a
|
|
href="http://esw.w3.org/topic/RdfCalendarMeetings">RdfCalendarMeetings</a></li>
|
|
<li><a
|
|
href="http://lists.w3.org/Archives/Public/www-rdf-calendar/">www-rdf-calendar</a>
|
|
mailing list</li>
|
|
<li><a href="/2000/01/foo.html"><cite>A quick look at iCalendar</cite></a>
|
|
by Tim Berners-Lee in 2001</li>
|
|
<li><a href="http://www.w3.org/DesignIssues/Notation3">Notation3</a>, <a
|
|
href="http://www.w3.org/2000/10/swap/Primer.html">N3 primer</a> work in
|
|
progress by Tim Berners-Lee</li>
|
|
<li><a
|
|
href="http://www.dajobe.org/2004/01/turtle/"><cite>turtle
|
|
- Terse RDF Triple Language</cite></a> by Dave Becket, work in progress
|
|
2005/08/17</li>
|
|
<li><a href="http://www.w3.org/2003/01/geo/">Basic Geo (WGS84 lat/long)
|
|
Vocabulary</a> work in progress by Dan Brickley et. al.</li>
|
|
<li><a
|
|
href="http://ietfreport.isoc.org/idref/draft-hare-xcalendar/"><cite>Guideline
|
|
for use of XML with iCalendar elements</cite></a>Internet Draft May-2005
|
|
by T. Hare</li>
|
|
<li><a href="http://web.resource.org/rss/1.0/modules/event/">RSS
|
|
Events</a>, work in progress 2002-07-30 by Søren Roug</li>
|
|
<li><a href="http://microformats.org/wiki/hcalendar">hCalendar</a> work in
|
|
progress 2004-2005 by Tantek Çelik and Brian Suda</li>
|
|
<li><a href="http://www.w3.org/DesignIssues/Diff.html"><cite>Delta: an
|
|
ontology for the distribution of differences between RDF graphs</cite>
|
|
</a>Berners-Lee and Connolly, work in progress 2001-2004</li>
|
|
<li><a href="http://xmlns.com/foaf/0.1/">FOAF</a>, friend of a friend by
|
|
Brickley et. al.</li>
|
|
</ul>
|
|
</body>
|
|
</html>
|