Issues regarding item clouds, permissioning etc...

From: AndiVajda
Date: 4/9/2004
To: dev@osafoundation.org
Subject: Issues regarding item clouds, permissioning etc...

Quite a few interesting and important meetings have been taking place over the past couple of weeks. Brian asked me to put my thoughts in writing. So, here we go:

Terminology

How do we name these things ? Item clouds, uppercase-I-items ? Interfaces ? Bundles ? Molecules (where lowercase-i-items are atoms) I find 'Interfaces' intriguing...

So, for now calling them Item Clouds, here is more about them.

They seem to be addressing several problems and occurred to several people at the same time almost. Serendipity at work. Neat.

They appear to fill the need of defining semantics for a set of items that work together in some fashion.

For example, an email item cloud can be viewed as the set of items made up by the email body, its headers, the addresses in its headers, its attachments, etc... where each of these pieces is actually implemented by an item and defined by a kind.

Uses

I see several uses for item clouds such as permissioning, sharing, exporting, or any other operation where there needs to be applied an operation to a semantically coherent set of items.

In permissioning: rather than permission each item inside a cloud, derive permissions to them from the permissions set at the entry point of the cloud and by following the cloud's boundaries. By default, everything inside a cloud inherits permissions from the entrypoint.

In sharing: when shipping an item from one Chandler to another, shipping along all items that are relevant with it, ie, the items that are most likely to be requested immediately after the entry point item was shipped over has the immediate advantage of significantly reducing roundtrips between two peers exchanging items.

In exporting: by exporting items, I mean exporting Chandler data to non-Chandler applications in a way that makes semantic sense at both ends of the transaction. For example, if I export an email, I do mean to export its headers and contents as well. An exporting module, could leverage the cloud concept to know which items belong together and implement some of the exporting code in terms of clouds and not just in terms of emails.

Clouds can of course overlap: The email cloud and the contact cloud probably overlap at the level of email addresses, for example. I believe that this addresses the very early Chandler vision of where an item could be looked at as one thing one time and another at a different time. Instead of achieving this with some re-kinding functionality, having clouds overlap (ie, have multiple different semantic entrypoints) achieves the same without any of the complexities behind re-kinding.

Implementation issues

Obviously, the concept of clouds should be represented in the schema instead of in code. That way much code can exploit it, and less code has to be written.

I've been thinking that the Kind item should be enhanced to describe the boundaries of the item cloud it serves as entrypoint for by maintaining a collection of reference attribute sequences that would be dereferenced when all the items in a cloud were collected. Brian has been thinking that such information should actually reside with the attributes themselves instead of the kind, a more attribute centric model. Both models are identical as long as kinds don't share attributes. If they do, which is something desirable and we intend to do, then storing the boundary information at the attribute level would also cause the boundaries at these attributes to be shared by their kinds. Choosing the latter model would cause us to move into a more attribute centric data model than we are today, a decision not to make lightly. We need to involve more people into this debate to raise the awareness about such a decision.

Currently I'm leaning towards yet another way to represent these boundaries. It came up during a recent conversation with Katie where she asked: "Why should there be only one such boundary per kind anyway ?" With that in mind we discussed the following: How about introducing the notion of Uppercase-K-kinds (need yet another name here) whose purpose is to define such item cloud groupings. A kind (lowercase-k) such as Email, would reference one or several of these uppercase-K-kinds for cloud boundary information. The choice of which uppercase-K-kind would be picked for the item-gathering operation would depend on the context of the operation in progress, such as permissioning, sharing or exporting. I currently like this idea a lot, I must admit... It provides a great opportunity for later extension. We could probably imagine storing more such cloud specific metadata there at a later time. I like such built-in extensibility a lot.

Permissioning

The issue here is simpler. Should the data model allow the definition of permissions at the attribute level (more precisely, at the attribute value level, on a per item basis) ?

Or should permissioning be done at the item instance level only ? Rephrasing the question: should the unit of permissioning be the same as the unit of access into the repository ? the item (lowercase-i). (of course, in both cases, appropriate defaults could be set at the kind and attribute item level).

Items may be defined by kinds for certain semantic purposes that I don't necessarily see easily aligning with permissioning granularity limited to the item. It is easy to imagine an Employee kind with various attributes of different sensitivities that would need to be permissioned separately.

Workphone, salary and SSN, for example, can be thought of as public, private and very-private levels of information sensitivity. If only the employee item can be permissioned then the more sensitive information would have to be moved into smaller items, referenced by the employee item, solely for the purpose of permissioning which, if taken to an extreme, could lead to lots of one-attribute items. I view this as undesirable.

Similarly, Pieter had raised an issue about different levels of sensitivity in information stored in a contact. While there may be an acceptable solution for this particular objection (contact sections), I don't think it addresses the original concern of forcing the item to satisfy two semantic needs, one defined by the kind, the other one defined by permissioning (which reflects information sensitivity).

Recommendations

These reflect my current thinking and could change as these conversations and meeting proceed, of course:

• item cloud boundaries should be represented on an uppercase-K-kind, a new data model concept to hold metadata and semantic information about items that work together.

• item clouds and uppercase-K-kinds need better names !!!

• permissioning needs to be built into the data model down to the attribute value level, although appropriate defaulting mechanisms using kinds and uppercase-K-kinds defined clouds should be used normally.

If you've read all the way down to here, thanks for your time !

Andi..

---

Here's the Original Email message which leads to some additional e-mail discussion