Expand on the following...
encoding / action / reltype / tzoffsetfrom / fbtype / repeat / altrep / range / fmttype / standard / daylight
This property defines the calendar scale used for the calendar information specified in the iCalendar object.
The only defined value for this property is the literal "GREGORIAN" (though this is case-insensitive). There's almost no need to include it explicitly, as it's the default.
4.7.1 Calendar Scale
This property defines the iCalendar object method associated with the calendar object.
This property is rarely used. The literal value "PUBLISH" is sometimes seen (also case-insensitive).
4.7.2 Method
This property specifies the identifier for the product that created the iCalendar object.
It's not clear exactly how this should be used in conjunction with RDF. If data is converted from iCalendar to RDF, should it identify the original product which generated the iCalendar data, or the tool that converted it to RDF? Syntactically the identifier must be a Formal Public Identifier.
[] ical:prodid "+//IDN cpan.org//NONSGML RDF::iCalendar::Exporter v 0.002//EN" .
In a vocabulary extension, define a predicate to indicate which doap:Project or doap:Version is identified by a particular FPI. (RFC 3151 is related.)
4.7.3 Product Identifier
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.
Currently 2.0 is the only version of iCalendar that exists, and that is the version number supported by this vocabulary. So the only possible values for this property are "2.0" or "2.0;2.0".
4.7.4 Version
This property is used to link from a calendar to a component (e.g. event) within it.
[ a ical:Vcalendar ] ical:component [ a ical:Vevent ] , [ a ical:Vevent ] , [ a ical:Vtodo ] .
The property provides the capability to associate a document object with a calendar component.
Typical usage would be to provide the URI of a document associated with the calendar component as a non-blank, non-literal RDF resource. data: URIs are particularly useful and are preferred over literal values, though consumers SHOULD support literal attachments, especially of type xsd:base64.
[] ical:attach <data:,This%20is%20a%20document.> . [] ical:attach "VGhpcyBpcyBhIGRvY3VtZW50Lg=="^^xsd:base64 .
4.8.1.1 Attachment
This property defines the categories for a calendar component.
The value of this property is a string containing a comma-delimited list of categories. Differences in the order of the list are not considered significant, nor are case differences. The meaning of non-literal values for this property is undefined. Consumers SHOULD try to treat the following as equivalent to each other:
[] ical:categories "Foo,Bar,Baz" . [] ical:categories "BAZ,BAR,FOO" . [] ical:categories "Foo", "BAR,BAZ" .
In a vocabulary extension, define a predicate which links an iCalendar component to a skos:Concept.
4.8.1.2 Categories
This property defines the access classification for a calendar component.
The defined values for this property are the literals "PUBLIC", "PRIVATE" and "CONFIDENTIAL" (though these are case-insensitive). "PUBLIC" is the default value to assume. Literal values beginning with "X-" are also allowed, as an extension point. This access control works almost entirely on "the honour system".
Explain that W3C access control list vocab can be used for finer-grained access control information.
4.8.1.3 Classification
This property specifies non-processing information intended to provide a comment to the calendar user.
An RDF plain literal is expected.
4.8.1.4 Comment
This property provides a more complete description of the calendar component, than that provided by the "SUMMARY" property.
An RDF plain literal is expected.
4.8.1.5 Description
This property specifies information related to the global position for the activity specified by a calendar component.
An rdf:List of two xsd:float literals is expected, in (latitude longitude) order. As usual, northern latitudes and eastern longitudes are assigned positive numbers; southern and western, negitive.
[ a ical:Vevent ] ical:geo (50.87363 0.01133) ; ical:location "Lewes, East Sussex, GB"@en .
This is really quite an annoying data structure but is specified by previous versions of this vocabulary. Can we change it?
4.8.1.6 Geographic Position
The property defines the intended venue for the activity defined by a calendar component.
An RDF plain literal is expected.
[ a ical:Vevent ] ical:geo (50.87363 0.01133) ; ical:location "Lewes, East Sussex, GB"@en .
An extension vocabulary should define a related property that takes a geo:SpatialThing as its value.
4.8.1.7 Location
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.
An xsd:integer literal value is expected.
4.8.1.8 Percent Complete
The property defines the relative priority for a calendar component.
An xsd:integer literal value is expected. Values from "1" to "9" represent high to low priority; value "0" means that no priority is assigned to the component; other values have an undefined meaning.
4.8.1.9 Priority
This property defines the equipment or resources anticipated for an activity specified by a calendar entity.
Values for this property use the same pattern used by the categories property.
4.8.1.10 Resources
This property defines the overall status or confirmation for the calendar component.
An RDF plain literal is expected. The allowed values, which are case-insensitive, depend on the component it's describing.
4.8.1.11 Status
This property defines a short summary or subject for the calendar component.
An RDF plain literal is expected. In practise, this represents the primary label for the calendar component.
4.8.1.12 Status
Dates and datetimes can be published in UTC, or a UTC offset using the xsd:date and xsd:dateTime datatypes. These are usually the best and most interoperable publishing method. However, sometimes this will be inappropriate - for example to represent an event that occurs at 9am every Friday in a locale that observes daylight savings, so has a different UTC datetime during the summer and winter periods. For these datetimes it is possible to mint a custom datatype using the ical:Vtimezone construct.
<#myEvent> a ical:Vevent ; ical:dtstart "2009-12-04T09:00:00"^^<#NewYorkTZ> ; ical:summary "Friday Breakfast Meeting"@en . <#NewYorkTZ> a ical:Vtimezone; ical:tzid "/softwarestudio.org/Olson_20011030_5/America/New_York"; ical:daylight [ ical:dtstart "1970-04-05T02:00:00"^^xsd:dateTime; ical:rrule [ ical:byday "1SU"; ical:bymonth "4"; ical:freq "YEARLY"; ical:interval "1" ]; ical:tzname "EDT"; ical:tzoffsetfrom "-0500"; ical:tzoffsetto "-0400" ]; ical:standard [ ical:dtstart "1970-10-25T02:00:00"^^xsd:dateTime; ical:rrule [ ical:byday "-1SU"; ical:bymonth "10"; ical:freq "YEARLY"; ical:interval "1" ]; ical:tzname "EST"; ical:tzoffsetfrom "-0400"; ical:tzoffsetto "-0500" ].
This property defines the date and time that a to-do was actually completed.
4.8.2.1 Date/Time Completed
This property specifies the date and time that a calendar component ends.
4.8.2.2 Date/Time End
This property defines the date and time that a to-do is expected to be completed.
4.8.2.3 Date/Time Due
This property specifies when the calendar component begins.
4.8.2.4 Date/Time Start
Shorter examples are included throughout this document in Turtle format. Here are some longer practical examples in RDF/XML and HTML+RDFa.
Many thanks to Robin Berjon for making our lives so much easier with his cool tool.