RDF vCard effort related to RDF iCalendar

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

RDF vCard effort related to RDF iCalendar

Garret Wilson
Everyone,

There's been a discussion on the semantic-web list regarding RDF vCard,
and I've been asked to share some of the discussion with this group
because my current RDF vCard proposals relate to RDF iCalendar.

As a bit of a background, I'm attaching two documents. The first is an
article I was writing, before I became aware of the semantic-web RDF
vCard effort, addressing why an RDF vCard format is needed and
advocating an approach to combining directory, vCard, and iCalendar.

The second document is a process document we've been discussing on the
list. It systematically takes [RFC 2425] (Directory), [RFC 2426]
(vCard), and [RFC 2445] (iCalendar) in an effort to create a consistent
set of RDF ontologies from them.

I realize that there has been substantial work on RDF iCalendar. It's
important at least to me personally that there is no duplication or
inconsistencies in RDF vCard/iCalendar work. I welcome your comments,
and feel free to join future semantic-web and/or online meetings
regarding our effort.

Garret

vCard in RDF: Problems and Resolutions

vCard in RDF: Problems and Resolutions

By Garret Wilson

Version 2007-03-27

Lead

A proposal for RDF representation of vCard, with implications for the RDF Calendar project and names in FOAF.

Metadata, Names, and the vCard

Metadata is not a new concept, and the idea of a name of a thing is one universal and very personal example of a metadata property that has existed since language began. The vCard, defined in RFC 2426, vCard MIME Directory Profile, is one standard method of storing and transferring metadata about a person, including that individual's name, address, and contact information. The vCard standard was defined early on in the Internet revolution, long before the release of the first RDF working draft, and it is still common to see vCards attached to emails, downloaded from web site, and used as a transfer mechanism between personal information managers such as Microsoft Outlook.

vCard was formulated before XML existed, and opts for its own simple text-based serialization. An example vCard appears below:

begin:vcard
version:3.0
fn:Dr. Mary Ann May Smith, Jr., M.D.
n:Smith;Mary;Ann,May;Dr.;Jr.,M.D.
n;language=es:Smith;Maria;Ann,May;Dr.;Jr.,M.D.
org:Example Corporation
adr;type=work,postal,parcel:;;123 Some Street;Springfield;NY;12345;USA
tel;type=voice,msg,work:+1-123-555-1212
email;type=internet,pref:[hidden email]
email;type=internet:[hidden email]
url:http://www.example.com/~jsmith
end:vcard

A single line from above example will help to better understand the general format of a vCard:

type;optionalParameters:single;value;or;structured;value
n;language=es:Smith;Maria;Ann,May;Dr.;Jr.,M.D.

As can be seen, each line of a vCard begins with a type, followed by an optional set of parameter=value pairs. In the example above, the type n indicates that this is a vCard name definition. The optional parameter language indicates by es that this is the Spanish form of the name. After that appears the value; for the n type, the value is a structured value separated by semicolons, with the components indicating family name, given name, additional names, honorific prefixes, and honorific suffixes, respectively.

In today's world, with the popularity of the XML syntax, the semantic rigor of RDF, and interoperable ontologies such as those provided by Dublin Core and FOAF, creating a representation of vCard in RDF+ML would seem ideal and obvious. Indeed, in 2001 there was an effort to create just such a formulation; the result can be seen in a 2001 <a href="Representing vCard Objects in RDF/XML">W3C Note, Representing vCard Objects in RDF/XML.

There are several problems that spring immediately from the existing RDF vCard specification, however:

  • Most obviously, the specification uses all uppercase for RDF property names, resulting in vcard:ORG, for example. Admittedly asthetic, this style is out of step with the modern RDF convention of representing property names in example:mixedCase and representing type names using example:InitialUppercase.
  • Also out of step with modern practices—reflecting the early date at which the the specification was created—the document opts for rdf:Seq and rdf:Bag to represent multiple property values, rather that using the newer rdf:List construct.
  • Some properties have been invented out of necessity, but they are inconsistent. What is referred to as "Additional Names" in RFC 2426 (vCard) has been changed to simply vcard:Other in the note, for example.
  • Lastly, parts of the specification are simply broken. When explaining how to indicate that the type of a UID is a SSN, the specification indicates that a property should be given to an RDF literal: <vcard:UID vcard:TYPE="US-SSN">987-65-4320</vCard:UID>. Unfortunately, this is not only incorrect RDF+XML syntax, RDF has no facility for assigning property values to plain literals. This suggestion by the note simply will not work, full stop.

vCard and Directory

To find a comprehensive, rigorous, yet elegant solution for representing vCard in RDF, it is beneficial to take a step back and find out the context in which vCard was created. vCard was not created in a vacuum. The title of RFC 2426, vCard MIME Directory Profile, gives a hint about its status in life. vCard is formulated as a profile of a more general text/directory MIME storage format defined in RFC 2425, A MIME Content-Type for Directory Information , much in the same way that the FOAF Vocabulary Specification is an ontology of RDF. Most of the syntactical requirements of each vCard content line, and even many semantic entities such the language parameter type, are defined in RFC 2425 (Directory) and only included by reference in RFC 2426 (vCard). Many individual semantic elements specific to RFC 2426 (vCard), such as the meaning of the N name components, are in turn derived from ITU-T X.520 and X-521.

The relationship of vCard to the Directory syntax and framework is especially interesting because of another similar format that some have attempted to convert to RDF+XML: RFC 2445, Internet Calendaring and Scheduling Core Object Specification (iCalendar). The iCalendar format has recently become popular by providing interoperability among such applications as Apple's iCal and Mozilla's Sunbird. Although RFC 2445 (iCalendar) explicitly states that it is not technically a profile of RFC 2425 (Directory), it is "based upon the syntax" and "does reuse a number of elements" from that specification.

This close relationship among RFC 2425 (Directory), RFC 2426 (vCard), and RFC 2445 (iCalendar) becomes significant when formulating an RDF version of vCard. Some parts of an RDF vCard vocabulary might be better generalized in light of its relationship to a more general framework, Directory. Furthermore, the experience of efforts to create an RDF version of iCalendar, such as represented by the W3C's RDF Calendar Workspace, may have bearing on attempts to do the same with vCard and vice versa. (One obvious consideration that can be mentioned already is that the W3C RDF Calendar effort uses lowercase names for iCalendar RDF properties.)

The FOAF Name Problem

Related to this discussion is an ontological design issue that has been raised by the Friend of a Friend (FOAF) Project, which has a goal of "creating a Web of machine-readable pages describing people, the links between them and the things they create and do." The aforementioned FOAF Vocabulary Specification defines an RDF ontology that includes such types as foaf:Person and foaf:Organization. Also included are properties relevant to humans, such as foaf:name, foaf:mbox, foaf:homepage, and even foaf:myersBriggs and foaf:dnaChecksum (the latter of which is admitted to be "mostly a joke" to reiterate the purpose of FOAF in describing people).

FOAF obviously covers some of the same metadata ground as does vCard, especially with its foaf:name property. Also included are other name-related properties such as foaf:firstName, foaf:givenname, foaf:firstName, foaf:family_name, and foaf:surname. It has been noted that the syntax and semantics of these names seem haphazard, incomplete, and conflicting all at the same time. This FOAF name vocabulary issue has been under discussion since at least as far back as 2000, with no resolution yet reported and no progress apparent for the past few years as of 2007. One proposal, Names in Foaf, tries to combine the "adopt existing guidelines" and "roll your own" approaches by creating a single foaf:sortName property, the value of which is an ordered list of RDF classes, each representing a component of the name, such as in this example:


<foaf:Person>
  <foaf:sortName xml:lang="es" rdf:parseType="Resource">
    <rdf:li><foaf:FamilyName rdf:value="Smith"/></rdf:li>
    <rdf:li><foaf:GivenName rdf:value="Maria"/></rdf:li>
    <rdf:li><foaf:GivenName rdf:value="Ann"/></rdf:li>
    <rdf:li><foaf:GivenName rdf:value="May"/></rdf:li>
    <rdf:li><foaf:HonorificTitle rdf:value="Jr."/></rdf:li>
    <rdf:li><foaf:HonorificTitle rdf:value="M.D."/></rdf:li>
  </foaf:sortName>
</foaf:Person>
</rdf:RDF>

While this proposal makes no explicit reference to RFC 2426 (vCard) and its predecessor specifications, the similarity is striking. There are some detractions from this proposal, though:

  • On the face of it, it's convoluted. The actual name components are indicated by property, but by class name. Furthermore, their relationship to the resource is that of an rdf:li property of a blank node value of the foaf:sortName property.
  • Using the rdf:li property, here again, is outdated and, as used, not defined by the standard. Apparently the blank node value of foaf:sortName is being used as a sort of un-typed rdf:Seq, even though this is not made explicit. A more modern approach would be to use an rdf:parseType of Collection to create an ordered rdf:List, but the other issues listed here would still remain.
  • Although the similarity to an existing standard, vCard, is obvious, there is no defined relationship that would make conversion between frameworks straightforward as well as provide insight useful in other projects such as W3C's RDF Calendar project.

As a reaction to the complexity of this approach, another suggestion, Names in Foaf - An alternate proposal has been to do away with all properties except foaf:name. In their place would appear a small set of properties—foaf:familiarName, foaf:informalName, foaf:formalName, and foaf:fullName—reflecting the use of names in different situations. These new properties would abandon any semantic identification of name parts, making it difficult to machine-process identification subcomponents as well as transfer data round-trip from existing standards.

A useful solution to representing human names in RDF should be as simple as possible. However, it should not be so simple as to lose semantics when transferring data from existing formats. Basing a solution on an existing standard would be ideal, but the transformation to RDF should be based upon a set of rules that would provide consistency as well as completeness, allowing straightforward data round-tripping between representations. One solution that meets these criteria is presented here.

Directory, vCard, and iCalendar in RDF

Analogous to Python script logic that is described in the W3C RDF Calendar document, is is possible to create a set of conceptual rules that can be used to transform the Directory, vCard, and iCalendar formats to RDF ontologies. We can start with the RDF ontology namespaces and recommended XML prefixes, which will each represent one of the profiles or pseudo-profiles of Directory, and will give an indication of how the work is to be divided up:

directory
http://globalmentor.com/namespaces/directory#
vcard
http://globalmentor.com/namespaces/directory/card#
icalendar
http://globalmentor.com/namespaces/directory/calendar#

A set of guiding rules might then start as follows:

  • Each Directory type name shall be converted to an RDF property name within the respective ontology, using the syntactical form example:mixedCase. e.g. The vCard ORG type produces the vcard:org property.
  • Defined parameters for a type shall also appear as RDF properties of the property value resource, using the name form example:mixedCase. e.g. The Directory LANGUAGE parameter would be indicated by a directory:language property of a value resource such as vcard:Adr.
  • If a particular Directory type calls for a literal value yet specifies parameters for that value, or if a literal value appears in some other circumstance in which an RDF resource is necessary (such as as elements of rdf:List), a blank node shall be used as the property value with the literal value appearing as the property of the blank node's rdf:value property. e.g. The vCard ORG type, if language needs to be specified, would produce an vcard:org property with a blank node value that has both the directory:language property to indicate the language and also the rdf:value property to indicate the literal property value.
  • If a particular Directory type specifies a structured value, an RDF class shall be used to contain the elements of that stuctured value with a name in the form example:InitialUppercase. e.g. The value of the vCard ADR type would be represented as a vcard:Adr class that is the value of a vcard:adr property.
  • If a particular Directory type specifies a structured value, the components of which can be repeated but in which order is important, each structured value component shall be allowed to be represented either a single value or as an rdf:List value. If there is no official name defined for a particular structured value subcomponent, one shall be created that is as close as possible to the name used in the specification in referring to that component, using the example:mixedCase format. e.g. The subcomponent "Additional Name" of the vCard N type would appear as a vcard:additionalName property of the vcard:N class which would appear as a value of the vcard:n property. The value of the vcard:additionalName property could be single literal value; a blank node with its rdf:value set to the literal value (if, for instance, the directory:language needed to be specified for the value), or an rdf:List of blank nodes as just described (using a rdf:parseType of Collection in RDF+XML syntax, for example).

This produces the following RDF version of the name part of the vCard example introduced earlier, assuming that the properties are used to describe a foaf:Person:

<foaf:Person>
  <card:fn>Dr. Mary Ann May Smith, Jr., M.D.</card:fn>
  <card:n>
    <card:N>
      <card:familyName>Smith</card:familyName>
      <card:givenName>Mary</card:givenName>
      <card:additionalName rdf:parseType="Collection">
        <rdf:Description rdf:value="Ann"/>
        <rdf:Description rdf:value="May"/>
      </card:additionalName>
      <card:honoraryPrefix>Dr.</card:honoraryPrefix>
      <card:honorarySuffix rdf:parseType="Collection">
        <rdf:Description rdf:value="Jr."/>
        <rdf:Description rdf:value="M.D."/>
      </card:honorarySuffix>
    </card:N>
   </card:n>
  <card:n>
    <card:N>
      <card:language>es</card:language>
      <card:familyName>Smith</card:familyName>
      <card:givenName>Maria</card:givenName>
      <card:additionalName rdf:parseType="Collection">
        <rdf:Description rdf:value="Ann"/>
        <rdf:Description rdf:value="May"/>
      </card:additionalName>
      <card:honoraryPrefix>Dr.</card:honoraryPrefix>
      <card:honorarySuffix rdf:parseType="Collection">
        <rdf:Description rdf:value="Jr."/>
        <rdf:Description rdf:value="M.D."/>
      </card:honorarySuffix>
    </card:N>
   </card:n>
</foaf:Person>

About the Author

Garret Wilson provides consulting on Internet standards through his company, GlobalMentor, Inc..


Directory in RDF: A Process

Directory in RDF: A Process

By Garret Wilson

Version 2007-04-29

This document outlines a process for creating a specification for an RDF representation of [RFC 2425] (Directory), [RFC 2426] (vCard), and [RFC 2445] (iCalendar). As a process for presenting a definition of one or more RDF ontologies, this specification first declares a set of principles and a set of transformation rules that can be used to produce such an RDF ontology.

Principles

Before actually producing an RDF ontology, it is useful to determine what sort of ontology is desired. The following principals will guide the methodology used for producing an RDF version of directory information:

  • The ontology will be comprehensive. It will capture virtually all information that will be found in virtually all vCards. An RDF ontology that leaves unrepresented a significant amount of vCard information in existence would not be satisfactory.
  • The ontology will be complete. It will be specific and clear enough to provoide semantically equivalent round-tripping. If Processor A converts vCard A to RDF instance A, Processor B can convert RDF instance A to vCard B equivalent to vCard A solely be implementing the ontology specification and no other rules.
  • The ontology will be consistent with the respective RFCs. To the extent possible, the ontology will be able to be machine-produced by parsing RDF 2426 and following a set of rules.
  • The ontology will be modularized. It will take advantage of the relationship among Directory, vCard, and iCalendar so that, as much as possible, the same conversion rules and will be applicable to all three and will produce an ontology that can be reused among these and related specifications.

Namespaces

Taking into consideration the relationship among the Directory, vCard, and iCalendar specifications, there shall be three namespaces to identify three respective related ontologies:

directory: [RFC 2425] (text/directory)
http://www.w3.org/2007/directory/ns#
vcard: [RFC 2426] (text/directory, text/x-vcard)
http://www.w3.org/2006/vcard/ns#
icalendar: [RFC 2445] (text/calendar)
http://www.w3.org/2002/12/cal#

In addition, the following namespaces are referenced from other specifications:

xsd: XML Schema Part 2: Datatypes Second Edition
http://www.w3.org/2001/XMLSchema#

Naming Conventions

All RDF type and property names shall use mixed case or Camel Case. RDF type names shall use an initial uppercase character, and RDF property names shall use an initial lowercase character. This provides consistency with current naming practices. See:

Syntactic Entities/Components

Each component defined by the special type pair BEGIN and END should be represented by an RDF class. e.g. The value defined by the vCard BEGIN:VCARD/END:VCARD pair would be represented as a vcard:VCard class.

[RFC 2425] Directory Components
[RFC 2426] vCard Components
VCARD
[RFC 2445] iCalendar Components
VCALENDAR, VEVENT, VTODO, VJOURNAL, VFREEBUSY, VTIMEZONE, STANDARD, DAYLIGHT, VALARM
Source Name Description RDF Class
[RFC 2426] 1. VCARD To hold person object or white-pages type of directory information. vcard:VCard
[RFC 2445] 4.4 VCALENDAR The Calendaring and Scheduling Core Object is a collection of calendaring and scheduling information. icalendar:VCalendar
[RFC 2445] 4.6.1 VEVENT Provide a grouping of component properties that describe an event. icalendar:VEvent
[RFC 2445] 4.6.2 VTODO Provide a grouping of calendar properties that describe a to-do. icalendar:VToDo
[RFC 2445] 4.6.3 VJOURNAL Provide a grouping of component properties that describe a journal entry. icalendar:VJournal
[RFC 2445] 4.6.4 VFREEBUSY Provide a grouping of component properties that describe either a request for free/busy time, describe a response to a request for free/busy time or describe a published set of busy time. icalendar:VFreeBusy
[RFC 2445] 4.6.5 VTIMEZONE Provide a grouping of component properties that defines a time zone. icalendar:VTimeZone
[RFC 2445] 4.6.5 STANDARD A collection of properties that describe Standard Time. icalendar:Standard
[RFC 2445] 4.6.5 DAYLIGHT A collection of properties that describe Daylight Saving Time. icalendar:Daylight
[RFC 2445] 4.6.6 VALARM Provide a grouping of component properties that define an alarm. icalendar:VAlarm

Type/Property Names

Each Directory type name (or property name in iCalendar) should be converted to an RDF property. e.g. The vCard ORG type produces the vcard:org property. Some properties have no use in an RDF ontology because of their syntactic purpose, but are provided here for completeness.

[RFC 2425] Directory Types
SOURCE, NAME, PROFILE, BEGIN, END
[RFC 2426] vCard Types
FN, N, NICKNAME, PHOTO, BDAY, ADR, LABEL, TEL, EMAIL, MAILER, TZ, GEO, TITLE, ROLE, LOGO, AGENT, ORG, CATEGORIES, NOTE, PRODID, REV, SORT-STRING, SOUND, URL, UID, VERSION, CLASS, KEY
[RFC 2445] iCalendar Properties
CALSCALE, METHOD, PRODID, VERSION, ATTACH, CATEGORIES, CLASS, COMMENT, DESCRIPTION, GEO, LOCATION, PERCENT_COMPLETE, PRIORITY, RESOURCES, STATUS, SUMMARY, COMPLETED, DTEND, DUE, DTSTART, DURATION, FREEBUSY, TRANSP, TZID, TZNAME, TZOFFSETFROM, TZOFFSETTO, TZURL, ATTENDEE, CONTACT, ORGANIZER, RECURRENCE_ID, RELATED_TO, URL, UID, EXDATE, EXRULE, RDATE, RRULE, ACTION, REPEAT, TRIGGER, CREATED, DTSTAMP, LAST_MODIFIED, SEQUENCE, REQUEST-STATUS
Source Type/Property Name Description RDF Property Value Type Notes
[RFC 2425] 6.1. SOURCE To identify the source of directory information contained in the content type. directory:source Resource The CONTEXT parameter is abandoned because of complexity, partial obviation by the URI scheme designation, and few legacy data.
[RFC 2425] 6.2. NAME To identify the displayable name of the directory entity to which information in the content type pertains. directory:name Literal TBD: Replace with dc:Title?
[RFC 2425] 6.3. PROFILE To identify the type of directory entity to which information in the content type pertains. none N/A Obviated by inherent RDF typing.
[RFC 2425] 6.4. BEGIN To denote the beginning of a syntactic entity within a text/directory content-type. none N/A Syntactical element.
[RFC 2425] 6.5. END To denote the end of a syntactic entity within a text/directory content-type. none N/A Syntactical element.
[RFC 2426] 3.1.1 FN To specify the formatted text corresponding to the name of the object the vCard represents. vcard:fn Literal
[RFC 2426] 3.1.2 N To specify the components of the name of the object the vCard represents. vcard:n vcard:N
[RFC 2426] 3.1.3 NICKNAME To specify the text corresponding to the nickname of the object the vCard represents. vcard:nickname Literal
[RFC 2426] 3.1.4 PHOTO To specify an image or photograph information that annotates some aspect of the object the vCard represents. vcard:photo Resource ENCODING and TYPE abandoned as semantically unuseful and obviated by other properties. TBD: Sanction use of XPackage file:contentType as replacement for TYPE?
[RFC 2426] 3.1.5 BDAY To specify the birth date of the object the vCard represents. vcard:bday Literal, datatype xsd:dateTime
[RFC 2426] 3.2.1 ADR To specify the components of the delivery address for the vCard object. vcard:adr vcard:Adr; or rdf:List of vcard:Adr, the first element indicating preference TYPE parameter represented by vcard:adrType property
[RFC 2426] 3.2.2 LABEL To specify the formatted text corresponding to delivery address of the object the vCard represents. vcard:label Literal; or bnode with Literal rdf:value; or rdf:List of such bnodes, the first element indicating preference TYPE parameter represented by vcard:labelType property
[RFC 2426] 3.3.1 TEL To specify the telephone number for telephony communication with the object the vCard represents. vcard:tel Resource; or rdf:Llist of Resource, the first element indicating preference TYPE parameter represented by vcard:telType property; these are the same values as vcard:adr, but separate property created for consistency
[RFC 2426] 3.3.2 EMAIL To specify the electronic mail address for communication with the object the vCard represents. vcard:email Resource TYPE abandoned out of limited usefulness and few legacy data.
[RFC 2426] 3.3.3 MAILER To specify the type of electronic mail software that is used by the individual associated with the vCard. vcard:mailer Literal
[RFC 2426] 3.4.1 TZ To specify information related to the time zone of the object the vCard represents. directory:tz Literal Promoted to Directory ontology because of commonality with iCalendar.
[RFC 2426] 3.4.2 GEO To specify information related to the global positioning of the object the vCard represents. directory:geo directory:Geo Promoted to Directory ontology because of commonality with iCalendar.
[RFC 2426] 3.5.1 TITLE To specify the job title, functional position or function of the object the vCard represents. vcard:title Literal
[RFC 2426] 3.5.2 ROLE To specify information concerning the role, occupation, or business category of the object the vCard represents. vcard:role Literal
[RFC 2426] 3.5.3 LOGO To specify a graphic image of a logo associated with the object the vCard represents. vcard:logo Resource ENCODING and TYPE abandoned as semantically unuseful and obviated by other properties. TBD: Sanction use of XPackage file:contentType as replacement for TYPE?
[RFC 2426] 3.5.4 AGENT To specify information about another person who will act on behalf of the individual or resource associated with the vCard. vcard:agent vcard:VCard
[RFC 2426] 3.5.5 ORG To specify the organizational name and units associated with the vCard. vcard:org vcard:Org
[RFC 2426] 3.6.1 CATEGORIES To specify application category information about the vCard. vcard:categories rdf:List of bnodes with literal rdf:value
[RFC 2426] 3.6.2 NOTE To specify supplemental information or a comment that is associated with the vCard. vcard:note Literal
[RFC 2426] 3.6.3 PRODID To specify the identifier for the product that created the vCard object. vcard:prodid Literal
[RFC 2426] 3.6.4 REV To specify revision information about the current vCard. vcard:rev Literal, datatype xsd:dateTime
[RFC 2426] 3.6.5 SORT-STRING To specify the family name or given name text to be used for national-language-specific sorting of the FN and N types. vcard:sortString Literal
[RFC 2426] 3.6.6 SOUND To specify a digital sound content information that annotates some aspect of the vCard. By default this type is used to specify the proper pronunciation of the name type value of the vCard. vcard:sound Resource ENCODING and TYPE abandoned as semantically unuseful and obviated by other properties. TBD: Sanction use of XPackage file:contentType as replacement for TYPE?
[RFC 2426] 3.6.7 UID To specify a value that represents a globally unique identifier corresponding to the individual or resource associated with the vCard. none N/A UID property obviated by RDF's inherent identifier URI reference, which can be a UUID URN ([RFC 4122].
[RFC 2426] 3.6.8 URL To specify a uniform resource locator associated with the object that the vCard refers to. vcard:url Resource Value must not be a bnode.
[RFC 2426] 3.6.9 VERSION To specify the version of the vCard specification used to format this vCard. none N/A Ontology versioning is inherent in the VCard RDF namespace.
[RFC 2426] 3.7.1 CLASS To specify the access classification for a vCard object. vcard:class Literal
[RFC 2426] 3.7.2 KEY To specify a public key or authentication certificate associated with the object that the vCard represents. vcard:key TBD Is there something from the Web Of Trust (WOT) RDF Ontology we can use here?
[RFC 2445] CALSCALE This property defines the calendar scale used for the calendar information specified in the iCalendar object. icalendar:calscale
[RFC 2445] METHOD This property defines the iCalendar object method associated with the calendar object. icalendar:method
[RFC 2445] PRODID This property specifies the identifier for the product that created the iCalendar object. icalendar:prodid
[RFC 2445] VERSION This property specifies the identifier corresponding to the highest version number or the minimum and maximum range of the iCalendar specification that is required in order to interpret the iCalendar object. icalendar:version
[RFC 2445] ATTACH The property provides the capability to associate a document object with a calendar component. icalendar:attach
[RFC 2445] CATEGORIES This property defines the categories for a calendar component. icalendar:categories
[RFC 2445] CLASS This property defines the access classification for a calendar component. icalendar:class
[RFC 2445] COMMENT This property specifies non-processing information intended to provide a comment to the calendar user. icalendar:comment
[RFC 2445] DESCRIPTION This property provides a more complete description of the calendar component, than that provided by the "SUMMARY" property. icalendar:description
[RFC 2445] GEO This property specifies information related to the global position for the activity specified by a calendar component. icalendar:geo
[RFC 2445] LOCATION The property defines the intended venue for the activity defined by a calendar component. icalendar:location
[RFC 2445] PERCENT_COMPLETE This property is used by an assignee or delegatee of a to-do to convey the percent completion of a to-do to the Organizer. icalendar:percentComplete
[RFC 2445] PRIORITY The property defines the relative priority for a calendar component. icalendar:priority
[RFC 2445] RESOURCES This property defines the equipment or resources anticipated for an activity specified by a calendar entity. icalendar:resources
[RFC 2445] STATUS This property defines the overall status or confirmation for the calendar component. icalendar:status
[RFC 2445] SUMMARY This property defines a short summary or subject for the calendar component. icalendar:summary
[RFC 2445] COMPLETED This property defines the date and time that a to-do was actually completed. icalendar:completed
[RFC 2445] DTEND This property specifies the date and time that a calendar component ends. icalendar:dtend
[RFC 2445] DUE This property defines the date and time that a to-do is expected to be completed. icalendar:due
[RFC 2445] DTSTART This property specifies when the calendar component begins. icalendar:dtstart
[RFC 2445] DURATION The property specifies a positive duration of time. icalendar:duration
[RFC 2445] FREEBUSY The property defines one or more free or busy time intervals. icalendar:freebusy
[RFC 2445] TRANSP This property defines whether an event is transparent or not to busy time searches. icalendar:transp
[RFC 2445] TZID This property specifies the text value that uniquely identifies the "VTIMEZONE" calendar component. icalendar:tzid
[RFC 2445] TZNAME This property specifies the customary designation for a time zone description. icalendar:tzname
[RFC 2445] TZOFFSETFROM This property specifies the offset which is in use prior to this time zone observance. icalendar:tzoffsetfrom
[RFC 2445] TZOFFSETTO This property specifies the offset which is in use in this time zone observance. icalendar:tzoffsetto
[RFC 2445] TZURL The TZURL provides a means for a VTIMEZONE component to point to a network location that can be used to retrieve an up-to-date version of itself. icalendar:tzurl
[RFC 2445] ATTENDEE The property defines an "Attendee" within a calendar component. icalendar:attendee
[RFC 2445] CONTACT The property is used to represent contact information or alternately a reference to contact information associated with the calendar component. icalendar:contact
[RFC 2445] ORGANIZER The property defines the organizer for a calendar component. icalendar:organizer
[RFC 2445] RECURRENCE_ID This property is used in conjunction with the "UID" and "SEQUENCE" property to identify a specific instance of a recurring "VEVENT", "VTODO" or "VJOURNAL" calendar component. The property value is the effective value of the "DTSTART" property of the recurrence instance. icalendar:recurrenceID
[RFC 2445] RELATED_TO The property is used to represent a relationship or reference between one calendar component and another. icalendar:relatedTo
[RFC 2445] URL This property defines a Uniform Resource Locator (URL) associated with the iCalendar object. icalendar:url
[RFC 2445] UID This property defines the persistent, globally unique identifier for the calendar component. icalendar:uid
[RFC 2445] EXDATE This property defines the list of date/time exceptions for a recurring calendar component. icalendar:exdate
[RFC 2445] EXRULE This property defines a rule or repeating pattern for an exception to a recurrence set. icalendar:exrule
[RFC 2445] RDATE This property defines the list of date/times for a recurrence set. icalendar:rdate
[RFC 2445] RRULE This property defines a rule or repeating pattern for recurring events, to-dos, or time zone definitions. icalendar:rrule
[RFC 2445] ACTION This property defines the action to be invoked when an alarm is triggered. icalendar:action
[RFC 2445] REPEAT This property defines the number of time the alarm should be repeated, after the initial trigger. icalendar:repeat
[RFC 2445] TRIGGER This property specifies when an alarm will trigger. icalendar:trigger
[RFC 2445] CREATED This property specifies the date and time that the calendar information was created by the calendar user agent in the calendar store. icalendar:created
[RFC 2445] DTSTAMP The property indicates the date/time that the instance of the iCalendar object was created. icalendar:dtstamp
[RFC 2445] LAST_MODIFIED The property specifies the date and time that the information associated with the calendar component was last revised in the calendar store. icalendar:lastModified
[RFC 2445] SEQUENCE This property defines the revision sequence number of the calendar component within a sequence of revisions. icalendar:sequence
[RFC 2445] REQUEST-STATUS This property defines the status code returned for a scheduling request. icalendar:requestStatus

Type/Property Parameters

Each defined parameter for a type/property should be converted to an RDF property. e.g. The iCalendar DELEGATED_FROM parameter would be indicated by a icalendar:delegatedFrom property. Some parameters have syntactical purposes and will not be appropriate for inclusion into an RDF ontology.

[RFC 2425] Directory Type Parameters
language, context, encoding, value
[RFC 2426] vCard Type Parameters
TYPE
[RFC 2445] iCalendar Property Parameters
ALTREP, CN, CUTYPE, DELEGATED-FROM, DELEGATED-TO, DIR, ENCODING, FMTTYPE, FBTYPE, LANGUAGE, MEMBER, PARTSTAT, RANGE, RELATED, RELTYPE, ROLE, RSVP, SENT-BY, TZID, VALUE

Structured Values

If a particular type/property specifies a structured value, an RDF class should be used to contain the elements of that stuctured value with a name derived from the type/property name. e.g. The value of the vCard ADR type would be represented as a vcard:Adr class that is the value of a vcard:adr property.

[RFC 2425] Structured Values
[RFC 2426] vCard Structured Values
N, ADR, GEO, ORG
[RFC 2445] iCalendar Structured Values
GEO, PERIOD, RECUR
Source Name Description RDF Class
[RFC 2426] 3.1.2 N To specify the components of the name of the object the vCard represents. vcard:N
[RFC 2426] 3.2.1 ADR To specify the components of the delivery address for the vCard object. vcard:Adr
[RFC 2426] 3.4.2 GEO To specify information related to the global positioning of the object the vCard represents. directory:Geo
[RFC 2426] 3.5.5 ORG To specify the organizational name and units associated with the vCard. vcard:Org
[RFC 2445] 4.8.1.6 GEO Information related to the global position for the activity specified by a calendar component. directory:Geo
[RFC 2445] 4.3.9 PERIOD A precise period of time. icalendar:Period
[RFC 2445] 4.3.10 RECUR A recurrence rule specification. icalendar:Recur

Structured Value Properties

Each structured value component should be represented by an RDF property. If there is no official name defined for a particular structured value subcomponent, one should be created that is as close as possible to the name used in the specification in referring to that component. e.g. The subcomponent "Additional Name" of the vCard N type would appear as a vcard:additionalName property of the vcard:N class which would appear as a value of the vcard:n property.

[RFC 2425] Structured Value Properties
[RFC 2426] vCard Structured Value Properties
N: Family Name, Given Name, Additional Names, Honorific Prefixes, Honorific Suffixes; ADR: post office box, extended address, street address, locality, region, postal code, country name; GEO: latitude, longitude; ORG: organizational name, originizational unit names
[RFC 2445] iCalendar Structured Value Properties
GEO: latitude, longitude; PERIOD: start, end, duration; RECUR: FREQ, UNTIL, COUNT, INTERVAL, BYSECOND, BYMINUTE, BYHOUR, BYDAY, BYMONTHDAY, BYYEARDAY, BYWEEKNO, BYMONTH, BYSETPOS, WKST
Source Type Name Property Name RDF Property Value Type Notes
[RFC 2426] 3.1.2 N Family Name vcard:familyName Literal Value can be a literal, a blank node with a literal rdf:value, or an rdf:List of such blank nodes.
[RFC 2426] 3.1.2 N Given Name vcard:givenName Literal Value can be a literal, a blank node with a literal rdf:value, or an rdf:List of such blank nodes.
[RFC 2426] 3.1.2 N Additional Names vcard:additionalName Literal Value can be a literal, a blank node with a literal rdf:value, or an rdf:List of such blank nodes.
[RFC 2426] 3.1.2 N Honorific Prefixes vcard:honorificPrefix Literal Value can be a literal, a blank node with a literal rdf:value, or an rdf:List of such blank nodes.
[RFC 2426] 3.1.2 N Honorific Suffixes vcard:honorificSuffix Literal Value can be a literal, a blank node with a literal rdf:value, or an rdf:List of such blank nodes.
[RFC 2426] 3.2.1 ADR post office box vcard:poBox Literal
[RFC 2426] 3.2.1 ADR extended address vcard:extendedAddress Literal
[RFC 2426] 3.2.1 ADR street address vcard:streetAddress Literal Value can be a literal, a blank node with a literal rdf:value, or an rdf:List of such blank nodes.
[RFC 2426] 3.2.1 ADR region vcard:region Literal
[RFC 2426] 3.2.1 ADR postal code vcard:postalCode Literal
[RFC 2426] 3.2.1 ADR country name vcard:countryName Literal The country name, not the country code, must be specified.
[RFC 2426] 3.4.2 GEO latitude directory:latitude Literal
[RFC 2426] 3.4.2 GEO longitude directory:longitude Literal
[RFC 2426] 3.5.5 ORG organizational name directory:name Literal This overloads the [RFC 2425] use of NAME, but the semantics seem to be the same.
[RFC 2426] 3.5.5 ORG organizational units directory:units rdf:List of blank nodes each with rdf:value of Literal.
[RFC 2445] 4.8.1.6 GEO latitude directory:latitude Literal
[RFC 2445] 4.8.1.6 GEO longitude directory:longitude Literal
[RFC 2445] 4.3.9 PERIOD start icalendar:start Literal of datatype xsd:dateTime
[RFC 2445] 4.3.9 PERIOD end icalendar:end Literal of datatype xsd:dateTime
[RFC 2445] 4.3.9 PERIOD duration icalendar:duration Literal of datatype icalendar:duration
[RFC 2445] 4.3.10 RECUR FREQ icalendar:freq Literal; one of secondly, minutely, hourly, daily, weekly, monthly, yearly TBD: use constants or URI values?
[RFC 2445] 4.3.10 RECUR UNTIL icalendar:until Literal of datatype xsd:dateTime
[RFC 2445] 4.3.10 RECUR COUNT icalendar:count Literal of datatype xsd:integer TBD: use xsd:integer or plain literal?
[RFC 2445] 4.3.10 RECUR INTERVAL icalendar:interval Literal of datatype xsd:integer TBD: use xsd:integer or plain literal?
[RFC 2445] 4.3.10 RECUR BYSECOND icalendar:bySecond rdf:List of blank nodes with rdf:value of Literal of datatype xsd:integer (0-59) TBD: use xsd:integer or plain literal?
[RFC 2445] 4.3.10 RECUR BYMINUTE icalendar:byMinute rdf:List of blank nodes with rdf:value of Literal of datatype xsd:integer (0-59) TBD: use xsd:integer or plain literal?
[RFC 2445] 4.3.10 RECUR BYHOUR icalendar:byHour rdf:List of blank nodes with rdf:value of Literal of datatype xsd:integer (0-23) TBD: use xsd:integer or plain literal?
[RFC 2445] 4.3.10 RECUR BYDAY icalendar:byDay rdf:List of blank nodes with rdf:value of Literal in the form [([+]ordwk/-ordwk)] weekday where ordwk is an integer (1-53) and weekday is one of su, mo, tu, we, th, fr, sa TBD: i18n
[RFC 2445] 4.3.10 RECUR BYMONTHDAY icalendar:byMonthDay rdf:List of blank nodes with rdf:value of Literal in the form ([+]ordmoday/-ordmoday) where ordmoday is an integer (1-31) TBD: i18n
[RFC 2445] 4.3.10 RECUR BYYEARDAY icalendar:byYearDay rdf:List of blank nodes with rdf:value of Literal in the form ([+]ordyrday/-ordyrday) where ordyrday is an integer (1-366) TBD: i18n
[RFC 2445] 4.3.10 RECUR BYWEEKNO icalendar:byWeekNo rdf:List of blank nodes with rdf:value of Literal in the form ([+]ordwk/-ordwk) where ordwk is an integer (1-53) TBD: i18n
[RFC 2445] 4.3.10 RECUR BYMONTH icalendar:byMonth rdf:List of blank nodes with rdf:value of Literal of datatype xsd:integer (1-12) TBD: use xsd:integer or plain literal?
[RFC 2445] 4.3.10 RECUR BYSETPOS icalendar:bySetPos rdf:List of blank nodes with rdf:value of Literal in the form ([+]ordyrday/-ordyrday) where ordyrday is an integer (1-366) TBD: i18n
[RFC 2445] 4.3.10 RECUR WKST icalendar:weekStart Literal; one of su, mo, tu, we, th, fr, sa TBD: i18n

Value Types

Each value type if possible should be replaced with an existing RDF typed literal data type such as those found in XML Schema Datatypes. As values should be equivalent regardless of lexical form, the lexical rules of the RDF data type will apply when the value is stored in RDF. Value types which indicate other resources (such as email addresses, telephone numbers, and existing entities such as vCards) will be indicated by normal RDF URI reference. e.g. The boolean Directory value type would be represented as a typed literal with the data type xsd:boolean.

[RFC 2425] Value Types
uri, text, date, time, date-time, integer, boolean, float, x-name, iana-token
[RFC 2426] vCard Value Types
binary, vcard, phone-number, utc-offset
[RFC 2445] iCalendar Value Types
BINARY, BOOLEAN, CAL-ADDRESS, DATE, DATE-TIME, DURATION, FLOAT, INTEGER, PERIOD, RECUR, TEXT, TIME, URI, UTC-OFFSET, x-name, iana-token
Source Value Type Description Value Type Notes
[RFC 2425] 5.8.4. uri Used to identify values that are referenced by a URI (including a Content-ID URI), instead of encoded in-line. xsd:anyURI TBD: Determine which properties expect a URI really expect a Resource with a URI specified.
[RFC 2425] 5.8.4. text xsd:string This value type will be represented by an RDF string datatype or a plain literal, depending on the context.
[RFC 2425] 5.8.4. date Based on a subset of the definitions in ISO 8601 standard. xsd:date
[RFC 2425] 5.8.4. time Based on a subset of the definitions in ISO 8601 standard. xsd:time
[RFC 2425] 5.8.4. date-time Based on a subset of the definitions in ISO 8601 standard. xsd:dateTime
[RFC 2425] 5.8.4. integer Used to express signed integers in decimal format. xsd:integer
[RFC 2425] 5.8.4. boolean Used to express boolen values. xsd:boolean
[RFC 2425] 5.8.4. float Used to express real numbers. xsd:float
[RFC 2425] 5.4. x-name Reserved for experimental use not intended for released products, or for use in bilateral agreements. none RDF obviates the need for syntactical extension rules.
[RFC 2425] 5.4. iana-token A publicly-defined extension token, registered with IANA. none RDF obviates the need for extension through IANA registration.
[RFC 2426] 2.4.1 BINARY Inline, encoded binary data. xsd:base64Binary It is expected that some binary properties, such as PHOTO, LOGO, and SOUND, can accept either xsd:base64Binary literal or resource values.
[RFC 2426] 2.4.2 VCARD Another vCard. Resource
[RFC 2426] 2.4.3 PHONE-NUMBER Telephone number. Resource The resource value must have a URI with a tel: scheme as defined in [RFC 3966].
[RFC 2426] 2.4.4 UTC-OFFSET Signed offset from UTC. icalendar:utcOffset Literal is in the format specified by [RFC 2426] 2.4.4 (e.g. -07:00).
[RFC 2445] 4.3.1 BINARY Inline binary data. xsd:base64Binary It is expected that some binary properties can accept either xsd:base64Binary literal or resource values.
[RFC 2445] 4.3.2 BOOLEAN A Boolean value. xsd:boolean
[RFC 2445] 4.3.3 CAL_ADDRESS A calendar user address. Resource The given resource must have a URI specified.
[RFC 2445] 4.3.4 DATE A calendar date. xsd:date
[RFC 2445] 4.3.5 DATE-TIME A calendar date. xsd:dateTime
[RFC 2445] 4.3.6 DURATION A duration of time. icalendar:duration Literal is in the format specified by [RFC 2445] 4.3.6 (e.g. P15DT5H0M20S).
[RFC 2445] 4.3.7 FLOAT A real number value. xsd:float
[RFC 2445] 4.3.8 INTEGER A signed integer value. xsd:integer
[RFC 2445] 4.3.9 PERIOD A precise period of time. none Although PERIOD is specified as a value type, it more resembles a structured value and therefore a separate class is specified elsewhere in this document.
[RFC 2445] 4.3.10 RECUR A recurrence rule specification. none Although RECUR is specified as a value type, it more resembles a structured value and therefore a separate class is specified elsewhere in this document.
[RFC 2445] 4.3.11 TEXT Human-readable text. xsd:string This value type will be represented by an RDF string datatype or a plain literal, depending on the context.
[RFC 2445] 4.3.12 TIME A time of day. xsd:time
[RFC 2445] 4.3.13 URI A uniform resource identifier (URI) type of reference to the property value. xsd:anyURI TBD: Determine which properties expect a URI really expect a Resource with a URI specified.
[RFC 2445] 4.3.14 UTC-OFFSET An offset from UTC to local time. icalendar:utcOffset Literal is in the format specified by [RFC 2426] 2.4.4 (e.g. -07:00) rather than [RFC 2445] 4.3.14 (e.g. -700), as the former is consistent with the lexical representation of xsd:dateTime.
[RFC 2445] 4.2.20 x-name none RDF obviates the need for syntactical extension rules.
[RFC 2445] 4.2.20 iana-token none RDF obviates the need for extension through IANA registration.

Value Representation

RDF allows simple one-to-one property-value correspondances, although a single value may be a list of values. The syntax of Directory, vCard, and iCalendar allows for many properties to have a one-to-many relationship with values, in which a single property may contain one or more values. Furthermore, the RDF data model makes restrictions on where literals may appear in an RDF instance (e.g. string literals cannot appear as a subject of an RDF statement, nor may they appear as elements in a list). To compensate for these disparities, the following rules shall be applied when representing Directory data in RDF:

  1. If possible, a property value should be represented as a single RDF resource or RDF literal.
  2. If a property allows multiple values for which order is insignificant, each value should be represented by a separate RDF property and value.
  3. If a property allows multiple values the order of which is significant (e.g. the vCard N type Additional Name component), or if a property inherently indicates that the value should be plural (e.g. the vCard CATEGORIES type), the RDF property value may be an rdf:List containing the multiple values.
  4. If a property calls for a literal value yet specifies parameters for that value, or if a literal value appears in some other circumstance in which an RDF resource is necessary (such as an element of rdf:List), a blank node shall be used as the property value with the literal value appearing as the property of the blank node's rdf:value property.

References

References

2007-04-29
  • Changed vCard and iCalendar namespace URIs to those used by the current respective W3C efforts.
  • Added data types.
  • Added composite value types.
Reply | Threaded
Open this post in threaded view
|

Re: RDF vCard effort related to RDF iCalendar

Dan Connolly

On Wed, 2007-05-02 at 14:20 -0300, Garret Wilson wrote:
[...]
> I realize that there has been substantial work on RDF iCalendar. It's
> important at least to me personally that there is no duplication or
> inconsistencies in RDF vCard/iCalendar work. I welcome your comments,
> and feel free to join future semantic-web and/or online meetings
> regarding our effort.

Wow... lots to digest.

At a glance... I don't see anything about the relationship
of the work you've done to the RDF calendar test suite.
Am I missing it? Can you help me find it?

Also, are you familiar with the change policy
for the http://www.w3.org/2002/12/cal namespace?

see section 7. Choosing a namespace policy
http://www.w3.org/TR/2005/NOTE-rdfcal-20050929/#collab

--
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E


Reply | Threaded
Open this post in threaded view
|

Re: RDF vCard effort related to RDF iCalendar

Garret Wilson

Dan Connolly wrote:
> At a glance... I don't see anything about the relationship
> of the work you've done to the RDF calendar test suite.
> Am I missing it? Can you help me find it?
>  

I unfortunately haven't yet looked in depth at the existing iCalendar
documents for three reasons. First, I couldn't find any comprehensive
document describing the entire iCalendar ontology in RDF. Secondly, my
foremost concern was vCard; iCalendar is of interest to me only in the
future.

Mostly importantly is that I decided, because I was creating a
specification based upon the interrelation among directory, vCard, and
iCalendar (and this doesn't seem to have been done before), I might as
well create it from scratch the way (I think) it should be done, and
then compare notes---which is what I'm doing now.

Taking this comprehensive approach has been productive. For example,
although iCalendar calls PERIOD a specialized value type (for which
normally one would create a typed literal), I've found that it is better
modeled as an RDF class on its own, allowing the icalendar:duration
property to re-use the iCalendar duration datatype. Another benefit has
been the recognition that UTC-OFFSET is inconsistent between vCard and
iCalendar; I've chosen the vCard syntax, as it more closely follows
xsd:dateTime.

> Also, are you familiar with the change policy
> for the http://www.w3.org/2002/12/cal namespace?
>  

I had seen that section before; why?

By the way, where is this iCalendar schema that I keep seeing mention of?

Garret

Reply | Threaded
Open this post in threaded view
|

Re: RDF vCard effort related to RDF iCalendar

Dan Connolly

On Wed, 2007-05-02 at 15:22 -0300, Garret Wilson wrote:
[...]
> > Also, are you familiar with the change policy
> > for the http://www.w3.org/2002/12/cal namespace?
> >  
>
> I had seen that section before; why?

Because any changes to the  http://www.w3.org/2002/12/cal namespace,
which you use in your document, have to follow that process.

If you mean to follow that process, very well. Otherwise, best
to pick a new namespace name.

> By the way, where is this iCalendar schema that I keep seeing mention of?

Umm... follow your nose... http://www.w3.org/2002/12/cal

--
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E


Reply | Threaded
Open this post in threaded view
|

Re: RDF vCard effort related to RDF iCalendar

Garret Wilson

Dan Connolly wrote:
> Because any changes to the  http://www.w3.org/2002/12/cal namespace,
> which you use in your document, have to follow that process.
>
> If you mean to follow that process, very well. Otherwise, best
> to pick a new namespace name.
>  

Without a doubt! The W3 namespace was used in this document as a
placeholder and a discussion starter, indicating the desire that the
different efforts converge. In fact, this document isn't even a
specification---it's sort of a systematic process for creating a
specification---a guide, if you will---although statements for a
specification naturally fall out of such a process.

>  
>> By the way, where is this iCalendar schema that I keep seeing mention of?
>>    
>
> Umm... follow your nose... http://www.w3.org/2002/12/cal
>  

Hmmm... There's http://www.w3.org/2002/12/cal/ical.rdf and
http://www.w3.org/2002/12/cal/icaltzd.rdf , but I couldn't find any
definitive description of the syntax for a UTF-OFFSET, the content of a
#Value_RECUR, a description of #List_of_Float, etc.

I realize I'm coming to this discussion late. I'll go over these schemas
more closely.

Garret

Reply | Threaded
Open this post in threaded view
|

Re: RDF vCard effort related to RDF iCalendar

Antoni Mylka

Garret Wilson napisaƂ(a):

>
> Hmmm... There's http://www.w3.org/2002/12/cal/ical.rdf and
> http://www.w3.org/2002/12/cal/icaltzd.rdf , but I couldn't find any
> definitive description of the syntax for a UTF-OFFSET, the content of a
> #Value_RECUR, a description of #List_of_Float, etc.
>
> I realize I'm coming to this discussion late. I'll go over these schemas
> more closely.
>
> Garret
>
>

I started working with icaltzd in october 2006 I've written an ical
crawler for the Aperture Framework [1]. Now Aperture has become a part
of the Nepomuk Social Semantic Desktop project [2] (funded by EU).

My work involves creating two ontologies that might be relevant for this
discussion. The first is the Nepomuk Contact Ontology. It's main purpose
is to describe entries in addressbooks. It evolved from vCard, but now
it became more generic. Each Contact has multiple Roles and each Role
can have multiple ContactMedia (PostalAddresses, EmailAddresses etc.).
My goal was that each vCard entry can easily be expressed with NCO, but
an NCO contact can contain much more information that can fit into a VCard.

The second one is NCAL - Nepomuk Calendar Ontology. This one is a
more-or-less direct adaptation of RFC 2445. We didn't use ICALTZD
directly because it's in OWL (while nepomuk uses RDFS-inspired Nepomuk
Representational Language) and because of the problems with ICALTZD.
There are more of them. I've gathered them in section 7.2 of the
document available from [6] I hope it will help to start a new
discussion about ICAL RDF.

A new discussion is all the more relevant because RFC 2445 is to become
obsolete within a couple of weeks. See [3], the section about goals an
milestones. The changes in the document are described in detail on the
IETF Calsify status page [4]. See [5] for the exact diff between RFC
2445 and the proposed 2445bis.

The draft of the documentation of the ontology I'm working on can be
downloaded from [6] Most of this document is probably irrelevant to you.
You could skim through the 5. section (the one inspired by vCard) but
the most interesting part is section 7. It contains a detailed account
of the things I didn't like in ICALTZD and a process I adopted when
creating NCAL. I guess NCAL might be a starting point for the new ICAL
ontology.

The Protege files with the ontology itself are available at [7].
Remember that this is a work in progress and just about anything may
change :). They will be officially released to the general public after
  acceptation by the Nepomuk Consortium.

All comments are welcome.

[1] http://aperture.sourceforge.net
[2] http://nepomuk.semanticdesktop.org
[3] http://www.ietf.org/html.charters/calsify-charter.html
[4] http://tools.ietf.org/wg/calsify/
[5]
<http://tools.ietf.org/wg/calsify/draft-ietf-calsify-rfc2445bis/draft-ietf-calsify-rfc2445bis-06.changes.html>
[6] http://www.dfki.uni-kl.de/~mylka/nie.pdf
[7] http://www.dfki.uni-kl.de/~mylka/nie.zip

--
Antoni Mylka
[hidden email]