Subject: Subject: Comments: Draft-many-iCal-ski -DIPS and DOPS

From: "greg fitzpatrick" <[email-masked]>
Date: Fri, 15 Oct 1999 03:41:52 +0100

---------------

Subject: Comments: Draft-many-iCal-ski - DIPS and DOPS 

With the help of these, perhaps silly, acronyms,  DIP and DOP, and DIT and
DOT I will try  illustrate a major inconsistency in RFC 2445. 

A DIT is a "by Description Identifiable Thing" and a DIP is a "by
Description Identifiable Person".

A DOP is the "Description Of a Person" and a DOT is the "Description Of a
Thing.

We will confine ourselves for now to DITS and DOTS.

In our world, a calendar object is a DOT.  It is the Description Of a Thing.
 The thing could be a meeting. The meeting is by description identifiable. 
The meeting is a DIT.   

Unfortunately (because it confuses things) a DOT, upon its instantiation, is
automatically a DIT as well, since it in turn can be described by another
DOT and so on like a train of cars.  But like the train, there is only one
last car; the caboose.  The caboose has no car behind it, in other words
there is a DIT which doesn't describe any other DIT.  Just one DIT is not
also simultaneously  a DOT!

Ex;

A hammer is a DIT.  John's book about the hammer is a DOT.  Eddy's book
criticizing Johns book is a DOT.  The on-line Dublin Core document 
appraising  Eddy's book is a DOT.

 And of course these publications are all DITS as well.

Lets look at the Dublin Core document.  It must be uniquely identified. It
has a Distinguishing Name, the date it was published, updated, who wrote it
and so forth.  Actually much of this DOT is actually busy selfdescribing
itself as a DIT.

Some information has to be entered which is actually about Eddy's book. 
Basically the same stuff as above, a uid, and a publishing date, and the
title and the author:Eddie and so on.  At this stage we have illustrated an
initial Dublin Core problem.  In pioneering Dublin Core, it was not
completely clear whether a tag was employed as its own self-DOT or as a DOT
for an external DIT.  

Not to mention how to accommodate John's book - not to mention the actual
hammer itself.  Without a telescopic tag structure, all metadata functional
advantages for the hammer and John's book about the hammer were lost as
these references were relegated to the free-text areas of the Dublin Core
document.                            

When I spoke of this in Oslo where I complained that the RFC 2445 property,
ORGANIZER, was a misnomer, since it referred to the publisher of the
calendar object describing the meeting and not the person actually
responsible for the meeting, the person we capriciously  refer to as the
WhodoUsue, the gathered group replied in unison

"It is the same person!".  

I maintain that the WhodoUsue and the calendar publisher can never be
assumed to be one in the same.  Just as the Dublin Core property, CREATOR,
the author of a book, can never be assumed to be the same person as the
creator of a DC object describing that book.  If I may say so, they are most
likely two different DIPS.

Apparently CALSCH people see calendar objects as DITS and not DOTS.  The
calendar object is seen as an instance where the vectors of time, space, a
bunch a people and an overhead projector intersect.   Whoever orchestrates
the instance does so by creating a calendar object which plots the
intersection and becomes its master.   I hope I am being fair here.  Correct
me if I am wrong.

But what happens if the event was already  planned before anybody thought to
publish it as a calendar object?  And this event had its organizer
(WhodoUsue).already?  And this WhodoUsue didn't give two hoots for computer
calendars.  And this was a big event so an Internet guide published it as a
calendar object? And it was downloaded by 5000 people?

Who is Who?  Who is the organizer and who is the publisher?

And what about the sporting event example in RFC 2445?  Where is the tag for
the "real" organizer of the game?  How is this valuable property to be
inherited by the numerous calendar objects created by various publishers to
publicize the game.

Unfortunately this is only the beginning.  RFC 2445 consistently avoids
declaring the DIT or DOT status of properties within the Change Management
and Relationship Component Properties.  Many of the tags which we have
introduced in Draft-many-iCal-ski, are there for the purpose of  making that
status clear.

    See Subject: Comments: Draft-many-ical-ski - DIPROLE vs PARTSTAT