r3 - 28 Apr 2004 - 21:39:00 - KatieCappsParlanteYou are here: OSAF >  Journal Web  >  ContributorNotes > KatieParlanteNotes > KatieParlante20040427

SubAttributes use cases

Collections

Disclaimer, this example is not the actual proposal for ItemCollections, but it gets the point across.

ItemCollection                      ContentItem
               members <--> membersOf

Calendar                            CalendarEvent
       itemsInCalendar <--> calendar

In this case, we wanted a general notion of members of a collection, and to know the collections a content item is a member of. In the specific case, we want special types of collections (Calendars). If an event is in a calendar collection, we want the attribute to be called 'calendar', not the vanilla 'membersOf'. An item that is in a calendar may also be in other item collections, so the list of calendars is indeed a subset of all the collections the item is a memberOf. Yes, we could model this other ways (and probably need to, in this case, as the true use case is actually more complex than given above.) The idea that we are experimenting with is that we want the attribute itself to be meaningful. In various contexts, the code could just ask the collection on the other side of the membersOf attribute whether or not it was a calendar, but that works less well for general code. It would be nice to be able to look at the CalendarEvent item in some general viewer that knows nothing about calendars, and be able to note the correct relationship, from the data in a generic fashion.

Movie, Book, Author, Creator

Schema (partial):

  • Movie (Kind)
    • director <--> directed
    • actor <--> actedIn
  • Book (Kind)
    • author <--> authored
  • Person (Kind)
    • directed <--> director
    • authored <--> author
    • actedIn <--> actor

  • author, director, actor are all subAttributes of creator <--> created

Data (partial):

  • DirtyRottenScoundrels actor SteveMartin
  • Shopgirl author SteveMartin

We don't want to type Person -- to have an Actor subKind and an Author subKind -- we want to type the relationship. In the Chandler repository, we could create a relationship Item to refine the relationship:

  • Movie (Kind)
    • creator <--> creator_inverse
  • Book (Kind)
    • creator <--> creator_inverse
  • Created (Kind)
    • role (Enumeration: director, author, actor)
    • creator_inverse <--> creator
    • created_inverse <--> created
  • Person (Kind)
    • created <--> created_inverse

We could model the same problem as above, code needs to recognize relationship kinds to behave correctly. Presumably, ItemClouds could help us here, although I don't think folks have tackled the issue of which cloud the relationship belongs in (only one? both?). In this case, bidirectional references seem almost beside the point, btw.

Imagine a generic viewer table that showed you a bunch of Items, with values for each Attribute in columns. If you wanted directed, authored, actedIn to be columns in the table, the code would have to know how to deal with "Created", or with relationship kinds in general. We've also lost the ability to have information about director, author, and actor (display name, etc.), unless we beef up the Enumeration to be a Kind with its own data. At any rate, either this ends up being special case code in each situation, or we have some idiom for relationship Kinds that is well understood. Perhaps we introduce a RelationshipKind.

Participants

  • participants (Attribute)
    • organizer
    • attendee
    • invitee
    • requestor
    • requestee

  • Events have participants, of different roles
  • Tasks have participants, of different roles
  • participant attributes have the value of AnyContact, which is an Alias for Contact, string or EmailAddress.

Because we want to track more information about the relationship, it probably makes sense to have an item for the relationship (a Kind called Participant) as Lisa is proposing: http://wiki.osafoundation.org/twiki/bin/view/Journal/LisaDusseault20040426

Dublin Core

The dublin core makes use of subProperties, the rdf inspiration of subAttributes. They describe subProperties as "refinements" of properties. If A has the property B, and B is a subproperty of C, that implies that A has the property of C as well. Once someone has defined a bunch of properties and subProperties, one can make use of them in a fairly lightweight way.

Random notes

  • I think its wrong to think of a ref-collection as an item. If an attribute has multiple values, and they are references, the ref-collection is a convenience for dealing with multiple attribute-value pairs -- it is not that the attribute has a value of List. For cases where we want the value to be a thing that is a list, we create a new item to represent the list (ItemCollection). By thinking about it this way, it helps make the subAttributes idea seem a bit less oddball.

  • My current thinking is that we can live without subAttributes, especially if they end causing attribute lookup in general to be slow. Even so, I don't think the idea is heavyweight or complex (rather the opposite) -- definitely unfamiliar, perhaps costly and probably avoidable.

-- KatieCappsParlante - 27 Apr 2004

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r3 < r2 < r1 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.