[Dev] Re: Meeting Notes from Data Model Meeting

[Micah Dubinko]

Greetings,

I'm glad to see progress on resolving the data model issues. What I've
seen so far is very encouraging.

I especially like that URLs have been used consistently in the
repository, and that they're called "URL", and not the stuffier and
more abstract "URI". Keeping terminology at a familiar level is a good
strategy.

On the terminology front, I have to say that every conversation I've
had about "Items" and "Things" has gotten confusing.
(DataModelMeeting22May2003 says "We used the terminology in Brian's
document", but I wasn't sure which document that was--apologies if this
has already been resolved)

My suggestion for terminology is to not use both "Item" and "Thing".
Just pick one. My preference would be "Item".

Another aspect that seems to be under discussion is whether an item can
be more than one KindOfThing. This will become important when Chandler
gets to the stage where an Email item can also (as a meeting request)
be an Event, or perhaps a Contact could get annotated with a Note.

A strawman approach I have heard is to have two separate Items which
are strongly linked in some way. I dislike this approach because then
two URLs are needed to identify what is conceptually a single thing.

Here's another strawman: that "KindOfThing" is more of an emergent
property than an absolute one. It would work like this:

At the Python API level, instead of:

item.getAkoURL()

there would be a slightly more object-oriented:

item.IsAko( url )

Additionally, I would expect some kind of indexing/iterators that would
efficiently allow one access to every Item that meets some IsAko( url )
predicate.

At the Repository level, instead of Ako Things as they currently exist,
you could have "Item Templates", which would have triples like this:

Event hasRequiredAttribute startTime
Event hasOptionalAttribute endTime
Event hasRequiredAttribute headline

With such properties, it would be possible to "calculate longhand"
whether any given Item meets the requirements to be a certain IsAko(),
given the URL of an "Item Template". Again, database-like optimizations
would make this more efficient in practice than calculating everything
longhand.

I also like that "Item Templates" feel more symmetrical with "Attribute
Templates".

One final note, about something I didn't see mentioned in the notes:
cycles.

Please, no.

"Weak" cycles are OK--where one item contains the URL of another Item,
and an explicit URL-dereference operation would be needed to make the
jump. "Strong" cycles, which would trip up someone trying to do a basic
tree-walk over the Repository, would be bad, and should only be used as
a last, last resort.

Thanks,

.micah

=====
Find out how XForms is changing how people gather and manage XML. Full text of my book in-progress online at http://dubinko.info/writing/xforms/

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com