- From: Harry Halpin <hhalpin@ibiblio.org>
- Date: Mon, 09 Apr 2007 20:34:48 -0400
- To: Garret Wilson <garret@globalmentor.com>
- Cc: semantic-web@w3.org
Garret Wilson wrote: > Everyone, > > I'm attaching version 2007-04-06 of the process document I've created > for Directory/vCard/iCalendar. It's starting to be pretty > comprehensive---it covers all the top-level classes of these three > specifications, and addresses all the top-level properties of vCard. Will give it a careful reading! > I should note here that I'm not trying to take over anyone's current > role or get in the way of Harry, Brian, or Norman editing the ontology > spec. I'm just trying to do some work to move the project forward, > because this is a specification that I personally really need done as > soon as possible, and I hope that my work can be useful in putting > together a W3C specification that we call can use. No problem. > In fact, I plan on making available an alpha version of a project in > just a few days that will start producing RDF vCard data, so there's a > few things that I'd like to nail down so that I won't start having the > whole legacy transitional data problem to deal with. If a few people > could give me their opinions on the following questions, I'd be grateful: We'll wrap as much as possible into the VCard spec, but some of this is outside of VCard, in particular the RDFCalendar and Directory parts. If at all possible, it would be better to split this into 3 documents with links to each other instead of one - and then put all 3 out as W3C notes. For RDF Calendar work, I'd get in touch with Dan Connolly. > 1. Do you plan on keeping "2006" in the namespace, or changing it to > "2007"? I'd say "2007", but it doesn't really matter---I just need > to know. Usually the namespace is kept to the year where work started, i.e. 2006, although now shortnamespaces are allowed. > 2. What is the reaction to having a separate Directory namespace that > would incorporate elements shared between vCard and iCalendar? In > other words, I'd much rather have a single directory:Geo class > than duplicate vcard:Geo and icalendar:Geo classes. That's what I would recommend, and then I'd be Directory in a separate namespace. However, I do think there's some fairly mature "geo" namespaces so we might just want to point it to them. > 3. What do people think of using namespaces that indicate the > vCard/iCalendar relationship with text/directory? That is, > http://www.w3.org/2007/directory/ns# for Directory, > http://www.w3.org/2007/directory/vcard/ns# for vCard, and > http://www.w3.org/2007/directory/icalendar/ns# for iCalendar? I would keep them distinct, as they can serve different purposes. > > The most important thing in the short term for me, then, is the > namespace division---can a few people give me their thoughts? > (Comments on the attached document are welcome, too.) > > Thanks, > > Garret > > ------------------------------------------------------------------------ > > > Directory in RDF: A Process > > By Garret Wilson > > Version 2007-04-06 > > 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| > > Source Name Description RDF Class > [RFC 2426] <http://www.rfc-editor.org/rfc/rfc2426.txt> 1. |VCARD| To > hold person object or white-pages type of directory information. > |vcard:VCard| > [RFC 2445] <http://www.rfc-editor.org/rfc/rfc2445.txt> 4.4 > |VCALENDAR| The Calendaring and Scheduling Core Object is a > collection of calendaring and scheduling information. > |icalendar:VCalendar| > [RFC 2445] <http://www.rfc-editor.org/rfc/rfc2445.txt> 4.6.1 > |VEVENT| Provide a grouping of component properties that describe an > event. |icalendar:VEvent| > [RFC 2445] <http://www.rfc-editor.org/rfc/rfc2445.txt> 4.6.2 > |VTODO| Provide a grouping of calendar properties that describe a > to-do. |icalendar:VToDo| > [RFC 2445] <http://www.rfc-editor.org/rfc/rfc2445.txt> 4.6.3 > |VJOURNAL| Provide a grouping of component properties that describe a > journal entry. |icalendar:VJournal| > [RFC 2445] <http://www.rfc-editor.org/rfc/rfc2445.txt> 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] <http://www.rfc-editor.org/rfc/rfc2445.txt> 4.6.5 > |VTIMEZONE| Provide a grouping of component properties that defines a > time zone. |icalendar:VTimeZone| > [RFC 2445] <http://www.rfc-editor.org/rfc/rfc2445.txt> 4.6.5 > |STANDARD| A collection of properties that describe Standard Time. > |icalendar:Standard| > [RFC 2445] <http://www.rfc-editor.org/rfc/rfc2445.txt> 4.6.5 > |DAYLIGHT| A collection of properties that describe Daylight Saving > Time. |icalendar:Daylight| > [RFC 2445] <http://www.rfc-editor.org/rfc/rfc2445.txt> 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) 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| > > Source Type/Property Name Description RDF Property Value Type Notes > [RFC 2425] <http://www.rfc-editor.org/rfc/rfc2425.txt> 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] <http://www.rfc-editor.org/rfc/rfc2425.txt> 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] <http://www.rfc-editor.org/rfc/rfc2425.txt> 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] <http://www.rfc-editor.org/rfc/rfc2425.txt> 6.4. |BEGIN| > To denote the beginning of a syntactic entity within a text/directory > content-type. none N/A Syntactical element. > [RFC 2425] <http://www.rfc-editor.org/rfc/rfc2425.txt> 6.5. |END| To > denote the end of a syntactic entity within a text/directory > content-type. none N/A Syntactical element. > [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 3.1.1 |FN| To > specify the formatted text corresponding to the name of the object the > vCard represents. |vcard:fn| Literal > [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 3.1.2 |N| To > specify the components of the name of the object the vCard > represents. |vcard:n| |vcard:N||| > [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 3.1.3 |NICKNAME| To > specify the text corresponding to the nickname of the object the vCard > represents. |vcard:nickname| Literal > [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 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] <http://www.ietf.org/rfc/rfc2426.txt> 3.1.5 |BDAY| To > specify the birth date of the object the vCard represents. > |vcard:bday| Date Literal > [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 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] <http://www.ietf.org/rfc/rfc2426.txt> 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] <http://www.ietf.org/rfc/rfc2426.txt> 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] <http://www.ietf.org/rfc/rfc2426.txt> 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] <http://www.ietf.org/rfc/rfc2426.txt> 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] <http://www.ietf.org/rfc/rfc2426.txt> 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] <http://www.ietf.org/rfc/rfc2426.txt> 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] <http://www.ietf.org/rfc/rfc2426.txt> 3.5.1 |TITLE| To > specify the job title, functional position or function of the object > the vCard represents. |vcard:title| Literal > [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 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] <http://www.ietf.org/rfc/rfc2426.txt> 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] <http://www.ietf.org/rfc/rfc2426.txt> 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] <http://www.ietf.org/rfc/rfc2426.txt> 3.5.5 |ORG| To > specify the organizational name and units associated with the vCard. > |vcard:org| |vcard:Org| > [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 3.6.1 |CATEGORIES| > To specify application category information about the vCard. > |vcard:categories| |rdf:List| of bnodes with literal |rdf:value| > [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 3.6.2 |NOTE| To > specify supplemental information or a comment that is associated with > the vCard. |vcard:note| Literal > [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 3.6.3 |PRODID| To > specify the identifier for the product that created the vCard > object. |vcard:prodid| Literal > [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 3.6.4 |REV| To > specify revision information about the current vCard. |vcard:rev| > Date Literal > [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 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] <http://www.ietf.org/rfc/rfc2426.txt> 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] <http://www.ietf.org/rfc/rfc2426.txt> 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] > <http://www.ietf.org/rfc/rfc4122.txt>. > [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 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] <http://www.ietf.org/rfc/rfc2426.txt> 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] <http://www.ietf.org/rfc/rfc2426.txt> 3.7.1 |CLASS| To > specify the access classification for a vCard object. |vcard:class| > Literal > [RFC 2426] <http://www.ietf.org/rfc/rfc2426.txt> 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 > <http://xmlns.com/wot/0.1/> we can use here? > [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| > > > Type/Property Parameters > > Each defined parameter for a type/property shall 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] <http://www.rfc-editor.org/rfc/rfc2425.txt> Directory Type > Parameters > |language|, |context|, |encoding|, |value| > [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, 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 > |GEO|: latitude, longitude > > > 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 > > > RDF Properties > > [TODO complete] > > Copyright © 2007 GlobalMentor, Inc. <http://www.globalmentor.com/> > -- -harry Harry Halpin, University of Edinburgh http://www.ibiblio.org/hhalpin 6B522426
Received on Tuesday, 10 April 2007 00:35:30 UTC