Subject: SKiCal component property extensions - SKUID

From: "Greg FitzPatrick" <[email-masked]>
Date: Mon, 5 Feb 2001 11:47:23 +0100

We would like to submit the following component property as an addition to
the properties described in RFC2445.

 Property Name: SKUID

 Purpose: This property specifies a persistent, globally unique identifier
for the resource described by the calendar object.

 Value Type: TEXT

  Property Parameters: Non-standard property parameters can be specified on
this property.

 Description: This property provides a method for determining the definite,
authoritative and unique identification of a resource. SKUID differs from
the UID property defined in RFC2445 section 4.8.4.7.  Whereas UID identifies
a calendar component (SKiCal object), SKUID identifies the resource being
described by the calendar component.

  The SKUID itself MUST be a globally unique identifier. The generator of
the identifier MUST guarantee that the identifier is unique. There are
several algorithms that can be used to accomplish this. The identifier is
RECOMMENDED to be the identical syntax to the RFC822  addr-spec. A good
method to assure uniqueness is described in RFC-2445  , section 4.8.4.7
Unique Identification Numbers.

  Format Definition: The property is defined by the following notation:

skuid = "SKUID" skuidparam ":" text CRLF skuidparam
			*(   	; the following is optional,
				; and MAY occur more than
				; once
			(";" xparam) )

  Example: The following is an example of this property:

SKUID:[email-masked]

Motivation:   If George and Steve wish to plan a business meeting, they
might well initiate it through their calendar program.  They might be in the
midst of some sort of project and this meeting merely one in a series of
many.  This meeting might not have any special name.  The only reference to
it might just be the iCal calendar object describing the time, place and
other details.

In this example the iCal object shared between George and Steve is the
identifier of the meeting/event.  It is easy to see why nothing else is
really necessary.  The UID of the calendar object simply doubles as the UID
of the meeting.

As I write this, my family is watching a handball game on television.  I
know most people in America haven’t the slightest what that sport is, but
over here it is a big deal and the game being watched just happens to be the
world championship final between Sweden and France.

Quite a few Swedes and French are interested in this event and some of them
surely had it marked in their desk top calendar or PDA schedulers.  They
might have entered the event themselves or they might have downloaded a
readymade object from some sport site, perhaps in SkiCal, possibly they
subscribe to a service which sends out objects in accordance with some
preference profile they have on file.

In any case unless everyone got their calendar object from the same source,
they won’t share identical UIDs, and if they made the entry themselves, they
don’t share them with anybody at all.  This is the way it should be, because
the UID is the identifier of the calendar object and NOT the event it is
pointing to.

Here is what 2445 says:

4.8.4.7 Unique Identifier

   Property Name: UID

   Purpose: This property defines the persistent, globally unique
   identifier for the calendar component.

The point we are trying to make is that we also need an ID placeholder for
the unique identifier of the event itself.

Of course there may not always be a unique ID for an event.  We know for
example that the International Federation of Handball, who are the “owners”
of the World championships, do not publish their game schedules in SkiCal
(not yet in any case).

Actually it might just be one or more Infomediaries who takes it upon
themselves to define a unique identifier for events within their sphere.  If
that sounds difficult to imagine,  think about the ShowView system that
gives unique identifiers to all TV programs on European television.

Another parallel to this is travel books and the place they are describing.
The travel books have their ISBN numbers, edition sequencing, copyright
dates and so on but the place they are describing has its own identification
which all the books must somehow refer to.

---

From: John Stracke <[email-masked]>
Date: Mon, 05 Feb 2001 11:31:02 -0500

> described by the calendar component.

How exactly do you expect guarantee that the SKUID will be the same across all
SKiCal objects that describe the same resource? If the resource's own organizer
does not generate a SKUID, then everybody who publishes a SKiCal object for it
will generate their own SKUID.  If the resource's organizer does generate a
SKUID, then they're probably publishing their own SKiCal object, so why would
somebody else publish a different one?

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |"Millions of dollars of profits is what happens|
[email-masked]|in the absence of good design." -- Keith Moore |
\================================================================/

---

From: Pär Lannerö <[email-masked]>
Date: Tue, 06 Feb 2001 00:41:37 +0100

John Stracke wrote:
> SKiCal objects that describe the same resource? 

We cannot guarantee this. But it would be useful if one day all public
events and other resources (skisources) would have a globally unique id.
(For example, it would be possible to quickly find out what different
public calendars write about the same event if all use the same
identifier.) Defining a property to keep such an id is a first step
towards that scenario. 

The next logical step is to specify how these id:s should be located and
passed around. That work remains to be done. It will never be possible
to guarantee that no two objects (with non-identical SKUID values) refer
to the same skisource, but it is quite nice for people who *want* to
indicate that their SKiCal object refers to the same skisource as
another to be *able* to do this.

In a perhaps not-so-distant future there will be large calendar
databases containing SKiCal objects describing lots of skisources of
public interest. In many cases it will be a matter of a simple search
through one of those databases to find out whether or not the skisource
is already mentioned by somebody. If it is, you can copy the SKUID, thus
augmenting the information value of the SKiCal object you're about to
create.

> If the resource's own organizer

Well, most publishers of public calendars, since they are editors, want
to formulate the SUMMARY and DESCRIPTION using their own words (and
perhaps language). Perhaps they want to add lots of new properties to
the SKiCal object as well. Hopefully they will reuse the SKUID, though.

/Pär

It's in the middle of the night here, hope my writing is not too
confusing! :)

---

From: John Stracke <[email-masked]>
Date: Tue, 06 Feb 2001 11:53:35 -0500

> events and other resources (skisources) would have a globally unique id.

Perhaps.  But why can't it be called UID?

> > If the resource's organizer does generate a
> perhaps language).

But this doesn't scale; with hundreds of thousands of events published per day, you
just can't afford to edit their descriptions.  A much more common scenario is one
in which the description of the event is created by one person and then sent out
via some sort of feed, which may be forwarded, amalgamated, or filtered, but is not
subjected to any human scrutiny before it reaches the end users.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Due to circumstances beyond your control, you|
[email-masked]|are master of your fate, and captain of your |
|                |soul.                                        |
\==============================================================/

---

From: Pär Lannerö <[email-masked]>
Date: Tue, 06 Feb 2001 18:15:17 +0100

> Perhaps.  But why can't it be called UID?

It could, but "UID" is already defined by 2445 to be a value
automatically generated whenever a new iCalendar object is created.
There is no ambition in 2445 to have one shared id between all calendar
objects (in separate calendaring systems) which refer to the same real
life event. Is there?

> just can't afford to edit their descriptions. 

Right, but not all calendars will keep hundreds of thousands of events
per day. One calendar site could specialize in for example "wine related
events in the London area". The editor of such a site will have his
search engine find every such SKiCal object (using the metadata of
SKiCal objects). He or she will probably be able to put his own wording
to most of those events.

/Pär

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Tue, 6 Feb 2001 21:49:15 +0100

Both of you make good points in this discussion.

I always think of the example of a comet sighting.  Lets say that the
Stracke-Lannerö comet is going to visible at a certain time in certain areas
and that all sorts of infomediaries publish this as SKiCal objects .  Well
obviously nobody has the "right" or "ownership" to this event.  So there can
never be a single SKUID, though there might be one astronomical society that
does this, there could just as well be none or many.  This goes for all
kinds of natural phenomena which find their way in to almanacs and calendars

So we are going to have to live with multiple (or null) SKUIDs, but on the
other hand it is quite conceivable that theatre chains and universities and
sports organizations and what-have-you, including the organizers of meetings
do implement a system of UIDs even if only within their own sphere.

We need a placeholder for such useful and rigid designators.  The present
UID placeholder in 2445 was never meant for that function - and if we tried
to use it as such, where would be put the UID for the calendar object
itself?

Once again; there are resources and there are descriptions of resources and
these are separate entities.

Greg

/Pär

---

From: John Stracke <[email-masked]>
Date: Tue, 06 Feb 2001 16:07:21 -0500

Greg FitzPatrick wrote:

> The present

I don't think that UID *does* refer to the calendar object.  If it did, it'd
have to change on every iTIP message (or, at least, it couldn't be used in
REFRESH messages).  I think it refers to the event; the fact that there may be
multiple UIDs referring to the same event is regrettable, but not fatal.

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |"Your reality, sir, is lies & balderdash, and I|
[email-masked]|am pleased to say I have no grasp on it        |
|                |whatsoever!" --Baron Munchausen                |
\================================================================/

---

From: John Stracke <[email-masked]>
Date: Tue, 06 Feb 2001 16:09:58 -0500

> automatically generated whenever a new iCalendar object is created.

See my reply to Greg on why I think this definition of UID is wrong (I know it's what
2445 says, but then 2446 is inconsistent).

> One calendar site could specialize in for example "wine related

Then he'll have to worry about copyright problems; he may well have permission to
redistribute the data, but not to modify it.  Far safer to annotate it with out-of-band
comments.

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |Using strong crypto on the Internet is like    |
[email-masked]|using an armored car to transport money from   |
|                |someone living in a tent to someone living in a|
|                |cardboard box.                                 |
\================================================================/

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Wed, 7 Feb 2001 14:46:32 +0100

Ok, we have several discussions ongoing - I am not addressing extensibility
in this note, but "dualism"

I would really like to get some more comments on this.  John feels that iCal
as it stands can express dualism.  The SkiCal group reached the conclusion
that it can not and I think that Frank once explicitly said that there is no
issue of dualism what so ever.  I think he said, though I cant find that
mail just now, that the calendar object IS the event and that there does not
exist  two separate identities.

Since we feel that the iCal object is the pointer to an entity, we add
properties for the identification of that entity.  SKUID is only one of a
group of proposed SKiCal extensions that are meant to solve that problem.

We spent some long afternoons reviewing each 2445 property per se and asking
ourselves does this property serve the calendar object, the entity being
pointed to, or both.

We found for example that DTSTART and DTEND points to the entity, while
date/time created points back to the calendar object itself.  Since the
date/time created property is sorted under Change Management in 2445, I
assume the authors reached the same conclusion.  What is confusing is that a
meeting could originate (be conceived) in an Calendar application or it
could be conceived in some other method predating the Calendar object.  For
example, I assume that is how IETF meetings evolve.

Now lets say that the IETF had their own non-iCal method for scheduling
meetings, this may not be the case, but certainly all meetings are not
planned in iCal applications - some are merely originated on pen and paper,
but the attendees, having desktop and PDAs, will do there own scheduling on
a personal or company basis in iCal applications.

There will be "authorities" for the meetings and as subsequent calendar
objects are created there will be "authorities" for these objects viz.
ORGANIZER.  To be able to describe this dualism we felt necessitated to
create a new property as a place holder for the "organizer" of the actual
meeting.  We didn't want to "borrow" the ORGANIZER property for this
purpose, since it serves a necessary function as it stands.  Alas we wish
that the ORGANIZER term had not been used in 2445, because we feel that
PUBLISHER would have been more semantically apt.

So we, after hair pulling semantics discussions, arrived at the property
name; CONTROL.

  In a meeting (fictitious) meeting organized by Patrik Fältström, and where
someone in my company made up a schedule for the employees attending, the
calendar object could now reflect both "organizers"

SUMMARY: A particular applications area meeting
ORGANIZER;CN="Jenny Magnusson":MAILTO:[email-masked]
CONTROL;ROLE="Area Director";CN="Patrik Fältström":MAILTO:[email-masked]

Or take the property RELATED-TO for example, as it is defined in 2445.

"The property is used to represent a relationship or
   reference between one calendar component and another."

So here again, how do we express that the event itself is related to another
event?  How do we say that?  Our solution was to create a new property named
PARTREL so that in a situation where a particular (smaller) meeting was
being held at a particular (larger) conference the relationship of the two
could be defined even if there was no calendar object for the larger
conference itself.

SUMMARY: SKiCal BOF
PARTREL;RELTYPE=CHILD;CN=Joint W3C WAP
Forum:<[email-masked]

or in reverse

SUMMARY: Joint W3C-WAP Forum
PARTREL;RELTYPE=PARENT;CN=SKiCal BOF:<[email-masked]

Please understand that we are not out to increase the amount of properties,
we are only interested in improving the functionality.

BTW, this dualism discussion occurs everywhere infostructure architects
tread.  Dublin Core, for example, had to address the same problems, quite
some time after their original spec was mapped out.

> to use it as such, where would be put the UID for the calendar object

John Stracke:

I don't think that UID *does* refer to the calendar object.  If it did, it'd
have to change on every iTIP message (or, at least, it couldn't be used in
REFRESH messages).  I think it refers to the event; the fact that there may
be
multiple UIDs referring to the same event is regrettable, but not fatal.

---

From: John Stracke <[email-masked]>
Date: Wed, 07 Feb 2001 10:42:34 -0500

> calendar object could now reflect both "organizers"

OK, yeah, this is a good example.  Another would be a group of friends
organizing a trip to, say, a concert.  The concert was published with SKiCal;
the friends want to use iTIP to coordinate; a reasonable approach might be to
use iTIP had have the VEVENT contain the SKiCal extensions.  The concert's
identifier can't be used as the identifier in iTIP; what if two separate sets
of friends invite me to join them at the same concert? So, most likely, you'd
exchange iTIP messages whose VEVENTs were derived from the original SKiCal
VEVENT; in particular, they'd share the same SKUID.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"Collect call from reality, will you accept  |
[email-masked]|the--" *click*                               |
\==============================================================/

---

From: "Graham Gilmore" <[email-masked]>
Date: Wed, 7 Feb 2001 12:32:22 -0500

----- Original Message -----
From: "John Stracke" <[email-masked]>
To: <[email-masked]>
Sent: 07 February, 2001 10:42
Subject: Re: SKiCal component property extensions - SKUID - dualism

> VEVENT; in particular, they'd share the same SKUID.

    Isn't this type of tying-together of calendar objects the purpose of
the RELATED-TO property?

    Graham Gilmore

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Wed, 7 Feb 2001 20:44:13 +0100

Graham Gilmore wrote:

Greg:  I don't think so.  RELATED-TO allows us to express a relationship
between two calendar components, describing related yet different events.
As I understand it RELATED-TO is our cure for iCal's "flat" structure.  We
can not nest events and therefore we "relate" them.

But I think John meant this:

Cal object 1
     |
     |      ---------- Event 1  (SKUID)
     |
Cal object 2

Correct me if I am wrong John

---

From: John Stracke <[email-masked]>
Date: Wed, 07 Feb 2001 15:33:33 -0500

> Correct me if I am wrong John

Uh...not sure.

All I meant was that the event in the iTIP conversation could start out as a
copy of the SKiCal VEVENT, just as the event in a current iTIP conversation
starts out as a copy of a base iCalendar VEVENT.  The VEVENT in a REQUEST,
for example, would have the various SKiCal extensions.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"You're nothing but a pack of ringleaders!"  |
[email-masked]|--_Wyrd Sisters_, Terry Pratchett            |
\==============================================================/