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