|
--------------- 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 |