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:

• Use of Camel Case for Naming XML and XML-Related Components
• OASIS Naming Guidelines
• Expressing Dublin Core in HTML/XHTML meta and link elements

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

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

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

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

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

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

• Representing vCard Objects in RDF/XML
• An Ontology for vCards
• RDF Calendar Workspace
• RDF Calendar

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.

Copyright © 2007 GlobalMentor, Inc.