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.
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
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
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
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
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