[Dev] Issues regarding item clouds, permissioning etc...

[Andi Vajda]

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