[Data-modeling] Events, again

[Robert Cook]

On Mar 18, 2008, at 2:28 PM, Ryan Shaw wrote:

> 3) continue discussion of a generic "timeline" type, which would  
> allow the aggregation of events into arbitrary interesting groups.   
> For instance, you could have a timeline of volcanic eruptions, or of  
> major wars through history, or of dynasties in ancient Egypt.  There  
> was some discussion about this athttp://www.freebase.com/view/discuss/time#/ 
> guid/9202a8c04000641f8000000006f4819e if you're interested in  
> reading the thread.  The problem with timelines is that it's hard to  
> include eg. "birth of Albert Einstein" without creating an event for  
> that, whereas ordinarily in freebase we'd just look at the "date of  
> birth" property on the person to get their birthdate.  And I really  
> don't think we want to promote all dates in the system to be events,  
> do we?  Anyway, worth discussion, but can happen separately from the  
> two points above.
>
> Aren't things like this better handled through custom MQL queries?
>

Yes, I think so.  Making people events would be far to abstract to be  
useful to normal people.  I don't believe that we have the time-based  
equivalent primitive type the way we have with physical location (and  
even that one is touch and go -- witness the hell we've gone through  
for mailing addresses.)

One thing that comforts me is to know that we will layer higher-order  
semantics on top of our schemas over time.  Although we don't yet have  
this capability, I could easily imagine a property hint that says  
"this property represents the 'start time' for this type".  Such  
semantics could initially guide applications to create the proper MQL  
query to create a timeline with a heterogenous set of types, for  
instance.  If the property hint proved enough utility, it could be  
baked deeper into MQL for the convenience of future app developers.

I think about this every time we get too abstract in our data  
modeling.  We know that we are building for the future, but sometimes  
we undermine other goals by being too clever.  If the type cannot be  
understood by somebody adding data on the Freebase site or by a app  
developer who just wants something simpler than his MySQL database,  
then we've failed -- we will have an exquisitely modeled schema with  
no data in it.

Think of this is as "accretive semantics".  Start with something that  
provides local utility, and we will add semantics as proven necessary,  
rather than a priori.

R

> Ryan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freebase.com/pipermail/data-modeling/attachments/20080318/9a548b2c/attachment.htm