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

[Brian Douglas Skinner]

Thanks Andi,

I made a wiki page that has a copy of what you said in your dev list 
post about item clouds and permission:
http://wiki.o11n.org/twiki/bin/view/Journal/ItemCloudsAndPermissions20040409

And I also made a place on the main Data Model page for collecting links 
to pages that talk about Item Clouds and how to represent them:
http://wiki.o11n.org/twiki/bin/view/Chandler/DataModel#ItemClouds

- Brian



Andi Vajda wrote:
> 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..
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> 
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev