[Cosmo-dev] Sharing format questions

[Katie Capps Parlante]

Brian Moseley wrote:
> yes. this leads to another question - should cosmo require that items
> be stored in a hierarchy? what if we had our own "item soup" that you
> could PUT/GET/POST/DELETE into, as an alternative to putting them in
> structured collections with webdav?

Thought exercise related to your hierarchy question:

(1) Is the hierarchy used to define the "address" or URL of an item?

(2) Does the hierarchy define some semantic about the item? (What 
collection, calendar, project, etc. the item is in)

(3) Can items be in multiple places in the hierarchy?

(4) Can items move around in the hierarchy?

If the answer to #2 (hierarchy implies semantic information) is yes, 
then you want #3 (items in mulitple places) and #4 (items move around). 
Now you are confronted with storing the item twice or having some sort 
of "symlink" equivalent, which causes headaches when the item is removed 
from the first location.

If the answer to #1 (hierarchy is used as address) is yes, you are 
caught between not wanting the address of an item to go away for some 
client, and wanting to change the semantics of the item.

These tangles are part of the motivation for going with the "item soup" 
way of looking at things in the original chandler repository. Similarly, 
the user's model of these items is not that they reside in a master 
hierarchical folder/filesystem. This doesn't mean that there will never 
be ways to navigate the space using hierarchical views, but that there 
isn't one master hierarchy that is used to both determine how 
information is viewed as well as encode semantics about the items.

A longer discussion about hierarchies/alternatives from the user's 
perspective:
http://wiki.osafoundation.org/bin/view/Journal/HierarchyVersusFacetsVersusTags
http://wiki.osafoundation.org/bin/view/Journal/ClassificationPaperOutline2

> til now, cosmo's data model has been designed primarily according to
> webdav, but with the hibernate project we have the opportunity to
> redesign it in a more protocol-neutral way. not all of our data has to
> be directly mapped to webdav and friends (although it's easy to
> imagine a special webdav collection exposing an item soup if
> required).

Yup, agreed that it would make sense to have a webdav collection 
hierarchical view of the "item soup".

Cheers,
Katie