Re: "RDF Calendar - an application of the Resource Description Framework to iCalendar Data" is a W3C Interest Group Note

On Wed, 2005-10-12 at 12:52 -0600, Doug Royer wrote:
> In that document it says in part:
> 
>  > i.e. "this document is a Vcalendar with ... ." But we ran into a case
>  > of iCalendar data with more than one calendar in a file. There was
>  > some discrepancy among implementations as to whether this was good
>  > data; mozilla did not seem to accept it, but this was reported as a
>  > bug#179985 and indeed, section 4.4 iCalendar Object says
>  >
>  > The Calendaring and Scheduling Core Object is a collection of
>  > calendaring and scheduling information. Typically, this information
>  > will consist of a single iCalendar object. However, multiple iCalendar
>  > objects can be sequentially grouped together.
> 
> It is not that there are multiple calendars per file. Its that there
> can be multiple VCALENDARS objects per iCalendar object. RFC-2445 does
> not specify a calendar storage format.

No? It defined a MIME type.
http://www.w3.org/2002/12/cal/rfc2445#sec3.1

Where I wrote "file", read "mime body".

I suppose "multiple Calendars" is a bit sloppy.


>  It specifies a framework for
> exchanging calendar information, and not for exchanging calendars.
> RFC-2446 (iTIP) explains how to do the handshaking of the RFC-2445
> information.
> 
> As each VCALENDAR may only contain zero or one METHOD properties (see
> iTIP), and in order to represent multiple calendar requests that may
> contain both booked and scheduling (METHOD) objects, it is necessary
> to be able to allow for more than one VCALENDAR object in a transfer
> (More than one VCALENDAR object per iCalendar object)..
> 
> Later in the document:
> 
>  > We have explored using the iCalendar uid property to make URIs for
>  > event components2003-08-19. It's not clear whether events in separate
>  > files bearing the same uid should be considered identical or merely
>  > different views of the same event. For example, if they are identical,
>  > they have the same alarms. One approach that seems to work well is to
>  > use the uid as a fragment identifier rather than as a full URI.
> 
> RFC-2445 says: (Section 4.8.4.8, page 111):
> 
>    ... Description: The UID itself MUST be a globally unique
>        identifier....
> 
> And iTIP (RFC-2446) explains how to merge, compare, sorts
> and determine the order of components based on the METHOD
> SEQUENCE, DTSTAMP, and other properties. So, I am not sure why it
> is stated that it is not clear if they are versions of the same
> object.
>
> If specific implementations fail in one or more of the above it
> simply means they have bugs.

I doubt the identity issues discussed in the report are observable
via iTIP.

To elaborate a bit, suppose there's a softball game
tomorrow at 7pm, and you put it in your calendar with
uid softball123@example and invite me to it. Then
you add an alarm for 15 minutes ahead, and I add an alarm
20 minutes ahead. I also change the summary from
"softball game" to "Doug's softball game".

and I do an RDF query over the merge
of both of calendards a la

 SELECT ?E ?summary WHERE {
   ?E cal:summary ?summary;
      cal:component
         [ a cal:Valarm; cal:trigger [ cal:duration "-PT15M" ]],
         [ a cal:Valarm; cal:trigger [ cal:duration "-PT20M" ]].
  }.

If your calendar and my calendar give the same URI to the event
(say http://example/doug#softball123), then
If I get the following matches:

 ?E = <http://example/doug#softball123>
 ?summary = "softball game"

and

 ?E = <http://example/doug#softball123>
 ?summary = "Doug's softball game"


That means there's one event with two summaries. That conflicts
with saying that cal:summary is an owl:FunctionalProperty, which
is somewhat intuitive and would be useful for diff/sync purposes.


> >         http://www.w3.org/TR/2005/NOTE-rdfcal-20050929/
> >         http://www.w3.org/TR/rdfcal/

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Friday, 14 October 2005 18:28:15 UTC