Meeting Notes -- 18 Jun 2003

What

• Data Model -- review

When & Where

• Wednesday 18 Jun 2003 -- 2:00 to 3:15
• OSAF office in Belmont

Who attended

• John -- JohnAnderson
• Jurgen -- JurgenBotz
• Mitch -- MitchKapor
• Chao -- ChaoLam
• Lou -- LouMontulli (by phone)
• Katie -- KatieCappsParlante
• Ducky -- DuckySherwood
• Brian -- BrianDouglasSkinner
• Andi -- Andi Vajda

Agenda going in

• Have a general review meeting to go over the data model work that's been done in the past few weeks by Andi, Katie, John, and Brian. Have a chance to run it by everybody else in OSAF who's interested. Get a sanity check to make sure we're on the right track, and then do course-corrections accordingly.
• Documents to discuss
  • DataModelFeatureSummary
  • DataModelFeatureList
  • DataModelFeatureDetails

Highlights of what we talked about

• Intro
  • Katie presented our data model block diagram
  • Andy gave a review about the building blocks layer
  • Brian gave a quick description of the General Schema Layers above the building blocks

• some discussion of UUIDs
• some discussion of the building-block's programmer-level features of "names" and "paths" for items
• some discussion of user-level URLs for items, and their relationship (or lack thereof) to the building-block's programmer-level "names" and "paths"
• resolution: identified that "user-level URLs" is a topic that's missing from the DataModelFeatureList and needs to be planned for

• item versioning
  • some discussion of why "item versioning" was listed as a feature we want to cut from the data model
  • resolution: need to update the data model documents -- the current text, "features we want to cut", sounds like we mean "cut from chandler", where really we just mean "implement in parcel-specific code", up above the data model infrastructure
  • mitch: what we care about is versioning for end-user "information items" (like Contacts, E-mail messages, Tasks, Calendar Events, etc.), not for all potential items (like Agents, Queries, Notifications, etc.)
  • resolution: okay to to do item versioning just for information items, implemented in parcel-specific code, rather than have some database-level versioning features applied to all items automatically

• an item can be an instance of two kinds
  • discussion of the difference between items that are instances of kinds that have python code mapped to them (like "e-mail messages" and "calendar events"), vs. items that are instances of kinds that were created by end-users (like "baseball players" and "baseball teams")
    • end-user case is far simpler -- fine to strive to do that in a general way
    • the python-mapped case is much harder -- doing it in a fully general way would be a research project, and might not even be a sensible feature -- what would it even mean to allow a user to make an item be an E-mail message, and an Agent, and an AttributeDefinition? -- better to handle that in a special case way, for particular information items (E-mail messages, tasks, etc.)
  • some discussion in about the case of E-mail messages and Tasks, and the particular caveat about that in our earlier resolutions (see: DataModelFeatureDetails#Inheritance, and look for "data mixing")
  • Katie already owns the bugzilla task of looking at the Chandler PIM Schema issue of making sure that the Task/E-mail case

• queries
  • some discussion of the proposed resolution about "no text-based query language"
  • resolution: the phrase "no text-based query language" doesn't really convey what we mean -- parsing a query from text into a data structure isn't the hard thing that we're trying to avoid -- what we really mean is that we don't want to have a super-general query language like SQL, with features like joins -- specifically, for efficiency, we're talking about the possibility of making sure that queries run in some limited "context" (e.g. search my e-mail), rather than having a framework that assumes a super-general "rootless" query

• unicode
  • some discussion about the proposal to standardize on unicode -- discussion of UTF8 vs. unicode

• "Item Store" vs. "Object Store"
  • talked about storing "python objects" vs. "RDF triples" vs. "Chandler items"
  • resolution: we're going to have an "Item Store", that only stores Chandler items

• RDF
  • talked a little about our relationship to RDF -- what we will and will not be able to do, in terms of RDF interoperability
  • resolution: we need to develop a clear and consciously chosen story about RDF

Game plan coming out

• everyone present seemed to be okay with where we are now -- no major objections
• this is all still a work in progress -- we still have more decision making to do, and APIs to propose, and use cases to think out -- Andi, Katie, Brian, and John will all continue on their respective tasks

-- BrianDouglasSkinner - 19 Jun 2003