[Dev] Issues regarding item clouds, permissioning etc...
twl at osafoundation.org
Tue Apr 13 11:56:41 PDT 2004
Thanks for writing this up, it's definitely helpful to have it in this
On Apr 9, 2004, at 7:24 PM, Andi Vajda wrote:
> Quite a few interesting and important meetings have been taking place
> 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
> up by the email body, its headers, the addresses in its headers, its
> attachments, etc... where each of these pieces is actually
> 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,
> along all items that are relevant with it, ie, the items that are
> 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
> that this addresses the very early Chandler vision of where an item
> 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
> achieves the same without any of the complexities behind re-kinding.
One question that arises here is how/whether we need to resolve
conflicts that arise because of overlapping clouds. I think that the
answer is that we don't need to resolve conflicts, because a program
will only use a single item clound (point of view) at a time, which
will keep things consistent for that program's needs.
> - 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
> a collection of reference attribute sequences that would be
> when all the items in a cloud were collected. Brian has been
> 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.
> they do, which is something desirable and we intend to do, then
> 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
> 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
> such a decision.
I think that we need to stay with more kind based model, since we're
leaning in that direction. It will only be more confusing to be
some parts of the data model and attribute centric in other places.
> 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
> name here) whose purpose is to define such item cloud groupings. A
> (lowercase-k) such as Email, would reference one or several of these
> uppercase-K-kinds for cloud boundary information. The choice of
> uppercase-K-kind would be picked for the item-gathering operation
> depend on the context of the operation in progress, such as
> sharing or exporting. I currently like this idea a lot, I must
> It provides a great opportunity for later extension. We could
> imagine storing more such cloud specific metadata there at a later
> time. I like such built-in extensibility a lot.
I think that a separate holder for cloud boundaries is a good idea.
I'm not sure that I would call it a Kind, because it plays a different
role than regular kinds. Also, we only allow a single kind per item,
while we want to allow multiple Kinds (boundary specs) per kind. It
seems to me that a good start at a boundary specification is a
collection of paths (where the path segments are attribute names) from
the cloud entry point to items in the cloud. A cloud "instantiation"
would consist of the item corresponding to the entry point, and all
items that were reached by traversing each path in the boundary spec.
This also allows for the possiblity of shared items within the cloud,
which is good.
> - 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
> and attribute item level).
Seems to me that there are several choices for where to do
1. Items - permission each item
2. Attributes - permission each attribute
3. Cloud - permission an entire cloud at once, create several clouds
(Views) to grant differing levels of access
4. Cloud Path - like item but associated with the Cloud
I think that I like 3 the best, but that's just what I think today.
> 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
> attributes of different sensitivities that would need to be
> Workphone, salary and SSN, for example, can be thought of as public,
> private and very-private levels of information sensitivity. If only
> employee item can be permissioned then the more sensitive
> would have to be moved into smaller items, referenced by the
> 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
> Similarly, Pieter had raised an issue about different levels of
> sensitivity in information stored in a contact. While there may be
> 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
> by permissioning (which reflects information sensitivity).
> These reflect my current thinking and could change as these
> 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
> 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
> 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 !
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "Dev" mailing list
Ted Leung Open Source Applications Foundation (OSAF)
PGP Fingerprint: 1003 7870 251F FA71 A59A CEE3 BEBA 2B87 F5FC 4B42
More information about the Dev