Chandler's Virtuality Model is based on a faceted classification system.

My thinking about sets and item collection has been influenced by this model, and I've been assuming that we would use the values of attributes to define facets.

At the level of implementation, there are at least two ways to implement facets:

1. Use attributes of items to model facets. This can be done in a variety of ways: a) an attribute corresponds directly to a facet b) an attribute contains a list of an items facets. I'll refer to this as the attribute based approach.
2. Use collections/ref collections to model facets. Under this model you have one collection or ref-collection per facet. I'll refer to this as the collection based approach.

Here are some general pros-cons of the two systems:

Attribute based

Pros

* You don't need to know the precise collection(s) that the item will be added to. However, you do need to know which facet you're adding it to (whether that means a specific attribute value or item) --Morgen Yep.

Cons

* You need to write a filter expression to produce a collection that corresponds to a user collection.

Collection based

Pros

* The insert into a collection model may be more familiar/intuitive for developers

Cons

• If you assume one reference collection per facet, then every time you create a new facet, you need to create a new reference collection. Since we get the most mileage out of reference collections when they are bidirectional, this means adding the inverse attribute to any item that might have a particular facet, which implies a schema change each time you add a facet. I think you can just re-use the same attribute on ContentItem^? over and over for each facet, right? --Morgen -- Yes, you're right. It just means a little more code to sift through that (multi-valued) attribute.Actually, I think I am wrong. A Facet is tied to a particular attribute (as opposed to a Tag which is simply a value without an attribute), so adding a Facet like "Sphere" is adding an attribute to a Kind. Hmm, is "Sphere" a Facet or are the possible values such as "Personal", "Spouse", "Work" the Facets?
• You need to know which collection(s) items need to be inserted into and removed from. This becomes more difficult if the UI wants to remove an item from a Filtered, Union, Intersection, or Difference Collection, because you must find the source collection (and the correct source collection in the case of the binary operators (Union, Intersection, Difference)).

This table contains a sampling of Chandler use cases and how they might be modelled in the two approaches.

Use Case	Attribute based	Collection based
Sidebar: adding an item to a collection	add an attribute to the item being added	insert the item being added into the collection. If the collection is a FilteredCollection, add the item to the source of the FilteredCollection.
Sidebar: removing an item from a collection	remove an attribute from the item being removed	remove the item being removed from the appropriate collection. If the collection is a FilteredCollection, remove the item from the source of the FilteredCollection
Sharing: representing a collection in the sharee	Have a FilteredCollection over a BaseCollection of the items received from the Sharerer	have a BaseCollection of the Items received from the Sharer
Sharing: adding an item to the sharee's side of a collection	Change an attribute of the item being added, or add an item from the network to the BaseCollection	add the item from the sharee to the BaseCollection, which causes its XML file to be added, which causes it to be added on the sharer.
Sharing: removing an item from the sharee's side of a collection	Change an attribute of the item being removed	remove the sharee's item from the BaseCollection, which causes its XML file to be removed, which causes it to be removed on the sharer.