Abstract

This document is a recommendation from the CalConnect USECASE Technical Committee regarding the minimum interoperability of resources in the calendaring and scheduling domain.

Foreword

This document incorporates by reference the CalConnect Intellectual Property Rights, Appropriate Usage, Trademarks and Disclaimer of Warranty for External (Public) Documents as located at

http://www.calconnect.org/documents/disclaimerpublic.pdf.

1.  Methodology

The set of properties determined to be the minimum set for interoperability was chosen via discussion at CalConnect Roundtables and in conference calls of the USECASE Technical Committee. We used a three-pronged process to inform our selection of properties.

First, we conducted an informal survey of properties that are built into existing software products that feature manipulation of resources, which formed a starting point for further winnowing of properties. The software products were not selected by any formal process, but were those available to which committee participants had access. However, we believe these to be a fair representation of the types of calendaring, scheduling, and project management products currently in use. The software applications are:

Secondly, we created a set of use cases and from them extracted a plausible set of properties for the resources in the use cases.

Thirdly, during discussions we came to view resource interoperability as a case where a lack of structured data prevents transmission of useful information between systems. As we looked at attributes for calendar users, we observed a great degree of commonality between calendar user attributes, directory attributes, and vCard attributes. We also observed that implementations effectively repurpose user attributes for use by resources. Given this practical similarity between users and resources, we looked to vCard as a source for structured data that might aid interoperability in resources.

The result was a table of properties showing how many products used the property and the percentage of the total number of product that did so. (See Appendices)

2.  Observations

We observe that these fields are present, in one form or another, in all three sets of attributes:

3.  Discussion

The core issue for resource interoperability is enabling resource information, when encapsulated in, or transmitted with, an iCalendar object, to be viewed and understood in a manner that is actionable for the recipient. If the resource is a location, the recipient should be able find it; if a projector, learn its connectors and resolutions; if a piece of transport equipment, learn its carrying capacity and any certifications required for its operation, etc. This goal requires either that sufficient resource data be encapsulated within an iCalendar object or that a reference may be resolved to its canonical source.

Given these goals, our observations regarding the commonality of fields present in different recording systems, and the similarity between resource and user attributes, we looked to vCard as a mechanism for standardizing information for calendar resources. vCard and iCalendar have many similarities in their structured representation of localized data and data types, and they may prove highly compatible for resources as well as traditional users.

The congruence between vCard and iCalendar, and the loci that provide the possibility on which our recommendation is based, are found in the attributes of the ATTENDEE iCalendar property (see Appendixes Appendix D
(normative) and Appendix E
(normative) for the relevant sections of the Calsify and vCard drafts):

CUTYPE valuesKIND ValuesINDIVIDUAL*individual*GROUPgroupRESOURCE-ROOMUNKNOWN--
orgx-namex-nameiana-tokeniana-token
* indicates default value

We thus have a remarkable congruence between the current iCalendar specification for the attributes of an ATTENDEE and the two vCard properties SOURCE and KIND:

We observe, but have not met, a pragmatic need for additional metadata pursuant to resources. We observe that implementations leave the ResourceName field as an open text string. Customers may or may not have tools to classify their resources according to classes of local import. (e.g., cart, projector, dolly, laptop). We believe this area is ripe for improvement, perhaps in a series of customer-extensible key/value pairs, with population thereof and sorting exposed in the calendar user agents. Ideally, this information could also be encapsulated within an iCalendar object and available to external recipients.

4.  Recommendations

If an event participant’s vCard SOURCE is known, a calendaring system should populate the iCalendar ATTENDEE DIR field with that value. Calendar systems should enable the user to resolve and display the participant’s ( ATTENDEE‘s) data, as enabled and published by the vCard SOURCE. We observe that this functionality is equally valid for users and resources.

The potential values of iCalendar CUTYPE and vCard KIND should be the same in both standards. This direct mapping allows for increased use of vCard as a structured source for storing resource information.

We propose the CUTYPE/KIND attributes for “room” classification encapsulate the broader “venue” concept, perhaps leveraging work in VVENUE as a template for potential schema.

Bibliography

[1]  IETF RFC 3986, T. BERNERS-LEE, R. FIELDING and L. MASINTER. Uniform Resource Identifier (URI): Generic Syntax. 2005. RFC Publisher. https://www.rfc-editor.org/info/rfc3986.