- From: Dan Connolly <connolly@w3.org>
- Date: Fri, 14 Oct 2005 13:28:07 -0500
- To: Doug Royer <Doug@Royer.com>
- Cc: www-rdf-calendar@w3.org, Libby Miller <libby@asemantics.com>, semantic-web@w3.org
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