working notes on collections

Collections

• Ref-collection: The repository's notion of a collection. Any time one creates an attribute of cardinality list, type of some sort of Item, that implies a ref-collection. Ref-collection is a lower level construct. Higher level abstractions involving collections invariably involve ref-collections.
  • example: A calendar event might have a list of participants, contact information about people who are attending the event. That list is a ref-collection.

• ItemCollection: The user's notion of a collection of items. The design group is currently proposing three types of collections: Ephemeral, Ad Hoc, and Named Collection. All three will be implemented using an ItemCollection, a Kind implemented in the content model core.

• Query: The repository's mechanism for querying the repository.

• Rule: A user level construct, used to define searches and to build collections. The searches and collection building will be implemented using queries (at least most of the time).

• Content-spec: An attribute on any block, determining the content of that block. Summary views and detail views are implemented as blocks. For summary views, the content spec's value will be an ItemCollection. For detail views, the content spec's value will be a ContentItem.

Use Cases to implement in 0.4

• Home Calendar
• Work Calendar
• Thrask (email threads + other related content items)
• Groups based on organization
• Groups based on activity
• Projects
• All content items
• All content items by some Kinds
  • All contacts
  • All tasks
  • All calendar events
  • All notes
• Email based collections
  • Inbox
  • Sent

Notes

• ItemCollection logical attributes
  • name
    • straightforward Attribute
  • members
    • list of last known items that are members in the collection
    • ordered?
    • this is the set of items that shows up in the view
    • persisted? or generated? a cache?
    • bidirectional references?
  • explicit
    • list of items explicitly put in the collection, either by program action, user action
    • bidirectional references?
  • exceptions
    • list of items that the user has explicitly removed from the collection
    • could be a list of uuids
  • results
    • list of last known items in the result set from the query -- cached query results
  • rule
    • description of rule that dynamically determines membership
    • same as query? input to query?

• ItemCollection API
  • the python instances must act like python iterators -- length, next
  • ideally, would be good to act like python list -- index, order
  • must be able to iterate over a subset in the middle of the list (imagine scrolling in the middle of a long list)

• Ad hoc collections are a degenerate case of ItemCollection, all items are in the explicit list.

• Calendar and Project are subKinds of ItemCollection. Calendar and Project are also degenerate cases of ItemCollection, all items are in the explicit list. One could imagine creating a rule that goes along with a Calendar or Project, to identify items that will be added. Once an item is added, either because of a rule or through user action, the item is added to the explicit list. Membership in the collection is an attribute on the item, in this case.

• Named collections with rules are implemented using queries.

• All ad hoc and named collections are associated with at least one view. (Perhaps only one view in most cases). A View is a particular kind of Block.
  • Named collections are Summary Views and can be placed in the sidebar.

-- KatieCappsParlante - 16 Apr 2004