Meeting on Item Clouds, 22 April 2004

Attending: LisaDusseault, JeffreyHarris (by phone), TedLeung, (by phone), KatieCappsParlante, StuartParmenter, AndiVajda

---

Goals

Try to unify different understandings of what an Item Cloud is

Relevant Background

• DataModelPolicyPrimitiveProposal
• ItemCloudThoughts
• http://lists.osafoundation.org/pipermail/dev/2004-April/001356.html
• http://lists.osafoundation.org/pipermail/dev/2004-April/001367.html

Notes

Andi has completed a prototype implementation of Item Clouds. This implementation consist of a new Kind, "Cloud". There is a new attribute on Kind items which contains the Cloud Items associated with that Kind. Currently the implementation only works on reference attributes, but there is no technical reason why it cannot work on literal attributes. Andi noted that the repository tends to treat literals as a single unit, even though the developer sees several individual attributes. Katie asked about the impact on the Python mapping for items as well as on the repository's Python API. There is a single new piece of API on Cloud items called Cloud.getitem().

Katie also brought up the question of whether or not behavior could be associated with a Cloud. Andi said that he doesn't do this today, but it would be possible.

Another use case for Item Clouds might be specifying what data shows up in the user interface -- for example what information would be displayed in a detail view. There is something very view-like (in the database sense of the word view) about Item Clouds, at least insofar as describing subgraph of an item/attribute graph.

Ted felt that the design (as he understood it) was sensible. He had been concerned that another meta level might be introduced and was relieved to see that this was not the case.

Summary/Synthesis

An item cloud is a subgraph of an item/attribute graph (the graph obtained by looking at items and their attributes (both literal and reference). The sub graph is specified by a set of paths that are rooted a Kind. This Kind is called the Entry Point of the Item Cloud. Each path is a sequence of attribute names which are traversed from an Entry Point item to reach some End Point, which will either be a literal attribute or a reference attribute. All items that are encountered on some path in the Item Cloud are a part of the Item Cloud. Multiple item clouds can be associated with a Kind.

Each cloud can also have one or more policies associated with it. The policies determine what to do with the subgraph - transform for input/export, controll access, bundle up to reduce sharing round trips.

Open Issues

The following issues remain open:

• How are policies specified?
• What is the relationship to the parcel xml format/parcel loader?
• Is there any interaction with queries?
• How many Item Clouds will a parcel developer be required to write? Will this be too much of a burden?

Jeffrey also noted that he has been thinking about ItemClouds^? more from the perspective of solving the "schema merging problem". That is, given an item that is truly shared between two Chandlers, how do the Kinds on the originating Chandler get mapped to the Kinds on the receiving Chandler? This topic is worth several meeting of its own, and didn't get pursued much further.

Next Actions

• Andi to check his code into CVS
• Andi to proceed by trying to use his item cloud implementation to reduce the number of round trips in the existing sharing prototype
• Ted to write up meeting notes (done)
• Ted to review item cloud implementation
• Ted to incorporate Item Clouds into Data Model project.

-- TedLeung - 22 Apr 2004