W3C home > Mailing lists > Public > semantic-web@w3.org > April 2007

Re: more musings on RDF vCard and iCalendar

From: Leo Sauermann <leo@gnowsis.com>
Date: Tue, 17 Apr 2007 22:23:07 +0200
Message-ID: <46252CAB.8060803@gnowsis.com>
To: Garret Wilson <garret@globalmentor.com>
CC: semantic-web@w3.org, Antoni Mylka <antoni.mylka@gmail.com>
Although maybe unrelated:

We are currently working in the nepomuk.semanticdesktop.org project to 
write better versions of the W3C vCard / iCalendar ontologies. Better in 
terms of: more use of rdf constructs where needed. If you have worked 
with W3C vCard/iCal you may have noticed that there is room for 
improvement. This leads to a small information loss when transforming 
vCard-nepomukvcard-vCard.

If you are interested, bug me again in a month, then a first version 
should be ready.

NOTE: the ontologies created by us will very likely be used in much code 
(Aperture.sourceforge.net, nepomuk, nepomuk-kde, strigi) and may be 
useful for you and others.

please contact me for further questions,
best
Leo

It was Garret Wilson who said at the right time 02.04.2007 00:31 the 
following words:
> Harry and others,
>
> I've put together a document, attached, which sets forward principles 
> and processes to be used in creating one or more RDF ontologies for 
> directory/vCard/iCalendar. My point here is, rather than trying to 
> start with an RDF ontology and try to make it fit vCard data, I've 
> instead looked at the representation needs of 
> directory/vCard/iCalendar to see where it leads us regarding an RDF 
> ontology. This is a work in progress, and I'll be updating it in the 
> coming days.
>
> I believe I've covered most of the components of 
> directory/vCard/iCalendar, and it's leading me to some interesting 
> conclusions:
>
> 1. I'm now even more convinced that it would be inappropriate to 
> address vCard separate from other Directory types such as iCalendar. 
> Certain properties (e.g. GEO, UID, PRODID) are identical across 
> specifications. It would be a shame to have distinct and perhaps even 
> incompatible properties RDF vCard and RDF iCalendar, when they derive 
> from the essentially the same source.
>
> 2. The issue regarding components (such as with the vCard N property) 
> is very important yet luckily rare. There are only four so-called 
> structured values across all three specifications (and GEO is not even 
> really a problem), so we can safely create somewhat specialized 
> solutions for these classes.
>
> 3. I'm starting to become uncomfortable with the idea of having 
> specialized properties for different vCard TYPEs, such as 
> vcard:homeTel, for several reasons. First, and not insignificantly, is 
> the extent to which this will make translating from Directory vCard to 
> RDF vCard more convoluted---a simple vcard:telType would be simpler to 
> understand, and would allow for future processors to automatically 
> work with new types. Secondly, the idea of "type" in vCard is 
> semantically weak; currently TYPE for TEL means everything from 
> location ("home", "work"), technology used ("msg", "video"), to 
> whether the telephone number is the preferred one ("pref"). As there 
> are few cases in all three RFCs that actually use such a "type", I 
> think it better just to create a straightforward vcard:telType 
> property and leave in the legacy values for now---perhaps a more 
> comprehensive solution can be added later, rather than rigging a 
> complicated scheme now over what was inelegant to begin with.
>
> 4. Lastly, I've looked around and it seems that most other ontologies 
> are using CamelCase rather than hyphen-separated names; I recommend we 
> do the same.
>
> Note that some Directory properties in this document are duplicated 
> out of consistency, and will be collapsed when they are converted to 
> RDF ontologies. Likewise, if some properties are unnecessary (syntax 
> properties, for example) or redundant (a language property, for 
> example), they will be removed at a later stage.
>
> Again, this document is not yet an ontology specification in 
> itself---rather, I hope that everyone will think it logical and, after 
> some discussion, agree to incorporate some or all of its conclusions 
> into the actual specification. I welcome your thoughts.
>
> Best,
>
> Garret
>
> ------------------------------------------------------------------------
>
>
>   Directory in RDF: A Process
>
> By Garret Wilson
>
> Version 2007-04-01
>
> This document outlines a process for creating a specification for an 
> RDF representation of [RFC 2425] (Directory) 
> <http://www.rfc-editor.org/rfc/rfc2425.txt>, [RFC 2426] (vCard) 
> <http://www.ietf.org/rfc/rfc2426.txt>, and [RFC 2445] (iCalendar) 
> <http://www.ietf.org/rfc/rfc2445.txt>. Rather than immediately 
> 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] <http://www.rfc-editor.org/rfc/rfc2425.txt> 
> (|text/directory|)
>     |http://www.w3.org/2007/directory/ns#|
> vcard: [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 
> (|text/directory|, |text/x-vcard|)
>     |http://www.w3.org/2007/directory/vcard/ns#|
> icalendar: [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 
> (|text/calendar|)
>     |http://www.w3.org/2007/directory/icalendar/ns#|
>
>
>     Naming Conventions
>
> All RDF type and property names shall use mixed case or Camel Case 
> <http://en.wikipedia.org/wiki/CamelCase>. 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:
>
>     * Use of Camel Case for Naming XML and XML-Related Components
>       <http://xml.coverpages.org/camelCase.html>
>     * OASIS Naming Guidelines
>       <http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNamingCommentary.html>
>     * Expressing Dublin Core in HTML/XHTML meta and link elements
>       <http://dublincore.org/documents/dcq-html/>
>
>
>     Syntactic Entities/Components
>
> Each component defined by the special type pair |BEGIN| and |END| 
> shall 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] <http://www.rfc-editor.org/rfc/rfc2425.txt> Directory 
> Components
>
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> vCard Components
>     |VCARD|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> iCalendar Components
>     |VCALENDAR|, |VEVENT|, |VTODO|, |VJOURNAL|, |VFREEBUSY|,
>     |VTIMEZONE|, |STANDARD|, |DAYLIGHT|, |VALARM|
>
>
>     Type/Property Names
>
> Each Directory type name (or property name in iCalendar) shall be 
> converted to an RDF property. e.g. The vCard |ORG| type produces the 
> |vcard:org| property. Some propoerties have no use in an RDF ontology 
> because of their syntactic purpose, but are provided here for 
> completeness.
>
> [RFC 2425] <http://www.rfc-editor.org/rfc/rfc2425.txt> Directory Types
>     |SOURCE|, |NAME|, |PROFILE|, |BEGIN|, |END|
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 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] <http://www.ietf.org/rfc/rfc2445.txt> 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|
>
>
>     Type/Property Parameters
>
> Each defined parameter for a type/property shall be converted to an 
> RDF property. e.g. The Directory |LANGUAGE| parameter would be 
> indicated by a |directory:language| property of a value resource such 
> as |vcard:Adr|. Some parameters have syntactical purposes and will not 
> be appropriate for inclusion into an RDF ontology.
>
> [RFC 2425] <http://www.rfc-editor.org/rfc/rfc2425.txt> Directory Type 
> Parameters
>
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> vCard Type Parameters
>     |TYPE|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 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 shall 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] <http://www.rfc-editor.org/rfc/rfc2425.txt> Structured Values
>
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> vCard Structured Values
>     |N|, |ADR|, |GEO|, |ORG|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> iCalendar Structured 
> Values
>     |GEO|
>
>
>     Structured Value Properties
>
> Each structured value component shall be represented by an RDF 
> property. 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. 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] <http://www.rfc-editor.org/rfc/rfc2425.txt> Structured 
> Value Properties
>
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> vCard Structured 
> Value Properties
>     |N|: Family Name, Given Name, Additional Names, Honorific
>     Prefixes, and 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] <http://www.ietf.org/rfc/rfc2445.txt> iCalendar Structured 
> Value Properties
>
>
>     Value Types
>
> Each value type if possible shall be replaced with an existing RDF 
> typed literal data type such as those found in XML Schema Datatypes 
> <http://www.w3.org/TR/xmlschema-2/>. 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 
> |http://www.w3.org/2001/XMLSchema#boolean|.
>
> [RFC 2425] <http://www.rfc-editor.org/rfc/rfc2425.txt> Value Types
>     |uri|, |text|, |date|, |time|, |date-time|, |integer|, |boolean|,
>     |float|, |x-name|, |iana-token|
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> vCard Value Types
>     |binary|, |vcard|, |phone-number|, |utc-offset|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> iCalendar Value Types
>     |BINARY|, |BOOLEAN|, |CAL-ADDRESS|, |DATE|, |DATE-TIME|,
>     |DURATION|, |FLOAT|, |INTEGER|, |PERIOD|, |RECUR|, |TEXT|, |TIME|,
>     |URI|, |UTC-OFFSET|, |x-name|, |iana-token|
>
>
>     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.
>
>
>     RDF Classes
>
> [TODO]
>
>
>     RDF Properties
>
> [TODO complete]
>
> Source 	Type/Property/Parameter Name 	Description 	RDF Property
> [RFC 2425] <http://www.rfc-editor.org/rfc/rfc2425.txt> 	|SOURCE| 	To 
> identify the source of directory information contained in the content 
> type. 	|directory:source|
> [RFC 2425] <http://www.rfc-editor.org/rfc/rfc2425.txt> 	|NAME| 	To 
> identify the displayable name of the directory entity to which 
> information in the content type pertains. 	|directory:name|
> [RFC 2425] <http://www.rfc-editor.org/rfc/rfc2425.txt> 	|PROFILE| 	To 
> identify the type of directory entity to which information in the 
> content type pertains. 	|directory:profile|
> [RFC 2425] <http://www.rfc-editor.org/rfc/rfc2425.txt> 	|BEGIN| 	To 
> denote the beginning of a syntactic entity within a text/directory 
> content-type. 	|directory:begin|
> [RFC 2425] <http://www.rfc-editor.org/rfc/rfc2425.txt> 	|END| 	To 
> denote the end of a syntactic entity within a text/directory 
> content-type. 	|directory:end|
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 	|FN| 	To specify the 
> formatted text corresponding to the name of the object the vCard 
> represents. 	|vcard:fn|
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 	|N| 	To specify the 
> components of the name of the object the vCard represents. 	|vcard:n|
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 	|NICKNAME| 	To 
> specify the text corresponding to the nickname of the object the vCard 
> represents. 	|vcard:nickname|
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 	|PHOTO| 	To specify 
> an image or photograph information that annotates some aspect of the 
> object the vCard represents. 	|vcard:photo|
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 	|BDAY| 	To specify 
> the birth date of the object the vCard represents. 	|vcard:bday|
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 	|ADR| 	To specify 
> the components of the delivery address for the vCard object. 	|vcard:adr|
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 	|LABEL| 	To specify 
> the formatted text corresponding to delivery address of the object the 
> vCard represents. 	|vcard:label|
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 	|TEL| 	To specify 
> the telephone number for telephony communication with the object the 
> vCard represents. 	|vcard:tel|
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 	|EMAIL| 	To specify 
> the electronic mail address for communication with the object the 
> vCard represents. 	|vcard:email|
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 	|MAILER| 	To specify 
> the type of electronic mail software that is used by the individual 
> associated with the vCard. 	|vcard:mailer|
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 	|TZ| 	To specify 
> information related to the time zone of the object the vCard 
> represents. 	|vcard:tz|
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 	|GEO| 	To specify 
> information related to the global positioning of the object the vCard 
> represents. 	|vcard:geo|
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 	|TITLE| 	To specify 
> the job title, functional position or function of the object the vCard 
> represents. 	|vcard:title|
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 	|ROLE| 	To specify 
> information concerning the role, occupation, or business category of 
> the object the vCard represents. 	|vcard:role|
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 	|LOGO| 	To specify a 
> graphic image of a logo associated with the object the vCard 
> represents. 	|vcard:logo|
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 	|AGENT| 	To specify 
> information about another person who will act on behalf of the 
> individual or resource associated with the vCard. 	|vcard:agent|
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 	|ORG| 	To specify 
> the organizational name and units associated with the vCard. 	|vcard:org|
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 	|CATEGORIES| 	To 
> specify application category information about the vCard. 
> |vcard:categories|
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 	|NOTE| 	To specify 
> supplemental information or a comment that is associated with the 
> vCard. 	|vcard:note|
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 	|PRODID| 	To specify 
> the identifier for the product that created the vCard object. 
> |vcard:prodid|
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 	|REV| 	To specify 
> revision information about the current vCard. 	|vcard:rev|
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 	|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|
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 	|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|
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 	|UID| 	To specify a 
> value that represents a globally unique identifier corresponding to 
> the individual or resource associated with the vCard. 	|vcard:uid|
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 	|URL| 	To specify a 
> uniform resource locator associated with the object that the vCard 
> refers to. 	|vcard:url|
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 	|VERSION| 	To 
> specify the version of the vCard specification used to format this 
> vCard. 	|vcard:version|
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 	|CLASS| 	To specify 
> the access classification for a vCard object. 	|vcard:class|
> [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 	|KEY| 	To specify a 
> public key or authentication certificate associated with the object 
> that the vCard represents. 	|vcard:key|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|CALSCALE| 	This 
> property defines the calendar scale used for the calendar information 
> specified in the iCalendar object. 	|icalendar:calscale|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|METHOD| 	This 
> property defines the iCalendar object method associated with the 
> calendar object. 	|icalendar:method|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|PRODID| 	This 
> property specifies the identifier for the product that created the 
> iCalendar object. 	|icalendar:prodid|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|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] <http://www.ietf.org/rfc/rfc2445.txt> 	|ATTACH| 	The 
> property provides the capability to associate a document object with a 
> calendar component. 	|icalendar:attach|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|CATEGORIES| 	This 
> property defines the categories for a calendar component. 
> |icalendar:categories|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|CLASS| 	This 
> property defines the access classification for a calendar component. 
> |icalendar:class|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|COMMENT| 	This 
> property specifies non-processing information intended to provide a 
> comment to the calendar user. 	|icalendar:comment|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|DESCRIPTION| 	This 
> property provides a more complete description of the calendar 
> component, than that provided by the "SUMMARY" property. 
> |icalendar:description|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|GEO| 	This property 
> specifies information related to the global position for the activity 
> specified by a calendar component. 	|icalendar:geo|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|LOCATION| 	The 
> property defines the intended venue for the activity defined by a 
> calendar component. 	|icalendar:location|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|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] <http://www.ietf.org/rfc/rfc2445.txt> 	|PRIORITY| 	The 
> property defines the relative priority for a calendar component. 
> |icalendar:priority|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|RESOURCES| 	This 
> property defines the equipment or resources anticipated for an 
> activity specified by a calendar entity. 	|icalendar:resources|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|STATUS| 	This 
> property defines the overall status or confirmation for the calendar 
> component. 	|icalendar:status|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|SUMMARY| 	This 
> property defines a short summary or subject for the calendar 
> component. 	|icalendar:summary|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|COMPLETED| 	This 
> property defines the date and time that a to-do was actually 
> completed. 	|icalendar:completed|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|DTEND| 	This 
> property specifies the date and time that a calendar component ends. 
> |icalendar:dtend|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|DUE| 	This property 
> defines the date and time that a to-do is expected to be completed. 
> |icalendar:due|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|DTSTART| 	This 
> property specifies when the calendar component begins. 
> |icalendar:dtstart|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|DURATION| 	The 
> property specifies a positive duration of time. 	|icalendar:duration|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|FREEBUSY| 	The 
> property defines one or more free or busy time intervals. 
> |icalendar:freebusy|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|TRANSP| 	This 
> property defines whether an event is transparent or not to busy time 
> searches. 	|icalendar:transp|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|TZID| 	This 
> property specifies the text value that uniquely identifies the 
> "VTIMEZONE" calendar component. 	|icalendar:tzid|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|TZNAME| 	This 
> property specifies the customary designation for a time zone 
> description. 	|icalendar:tzname|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|TZOFFSETFROM| 	This 
> property specifies the offset which is in use prior to this time zone 
> observance. 	|icalendar:tzoffsetfrom|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|TZOFFSETTO| 	This 
> property specifies the offset which is in use in this time zone 
> observance. 	|icalendar:tzoffsetto|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|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] <http://www.ietf.org/rfc/rfc2445.txt> 	|ATTENDEE| 	The 
> property defines an "Attendee" within a calendar component. 
> |icalendar:attendee|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|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] <http://www.ietf.org/rfc/rfc2445.txt> 	|ORGANIZER| 	The 
> property defines the organizer for a calendar component. 
> |icalendar:organizer|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|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] <http://www.ietf.org/rfc/rfc2445.txt> 	|RELATED_TO| 	The 
> property is used to represent a relationship or reference between one 
> calendar component and another. 	|icalendar:relatedTo|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|URL| 	This property 
> defines a Uniform Resource Locator (URL) associated with the iCalendar 
> object. 	|icalendar:url|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|UID| 	This property 
> defines the persistent, globally unique identifier for the calendar 
> component. 	|icalendar:uid|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|EXDATE| 	This 
> property defines the list of date/time exceptions for a recurring 
> calendar component. 	|icalendar:exdate|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|EXRULE| 	This 
> property defines a rule or repeating pattern for an exception to a 
> recurrence set. 	|icalendar:exrule|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|RDATE| 	This 
> property defines the list of date/times for a recurrence set. 
> |icalendar:rdate|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|RRULE| 	This 
> property defines a rule or repeating pattern for recurring events, 
> to-dos, or time zone definitions. 	|icalendar:rrule|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|ACTION| 	This 
> property defines the action to be invoked when an alarm is 
> triggered. 	|icalendar:action|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|REPEAT| 	This 
> property defines the number of time the alarm should be repeated, 
> after the initial trigger. 	|icalendar:repeat|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|TRIGGER| 	This 
> property specifies when an alarm will trigger. 	|icalendar:trigger|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|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] <http://www.ietf.org/rfc/rfc2445.txt> 	|DTSTAMP| 	The 
> property indicates the date/time that the instance of the iCalendar 
> object was created. 	|icalendar:dtstamp|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|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] <http://www.ietf.org/rfc/rfc2445.txt> 	|SEQUENCE| 	This 
> property defines the revision sequence number of the calendar 
> component within a sequence of revisions. 	|icalendar:sequence|
> [RFC 2445] <http://www.ietf.org/rfc/rfc2445.txt> 	|REQUEST-STATUS| 
> This property defines the status code returned for a scheduling 
> request. 	|icalendar:requestStatus|
>
> Copyright  2007 GlobalMentor, Inc. <http://www.globalmentor.com/>
>
Received on Tuesday, 17 April 2007 20:24:14 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 21:45:14 GMT