[Data-modeling] Intervals as a primitive data type

[Tom Morris]

On Sat, Feb 21, 2009 at 6:32 PM, John Giannandrea <jg at metaweb.com> wrote:
>
> Tom Morris wrote:
>> There are a bunch of types with intervals specified using individual
>> properties like start_date/end_date, birth_date/death_date, etc.  If
>> these were encoded using a single property with an datetime_interval
>> as the type, they could be manipulated and compared much more
>> directly.
>
> There is a type, /measurement_unit/time_interval which can be used for
> this.

Thanks for the pointer.  I completely missed that because I was
looking in the time domain.  I can use that in my modeling even if it
doesn't get any additional support.

> The tradeoff seems to be whether it makes a type more or less
> accessible to have specific properties (like date_of_death) or a
> standard encoding which is one ply further out (a CVT).

There's also a storage & processing efficiency concern.  I was
actually thinking that both values would be stored in a single
primitive for efficiency of access and comparison, it might cost a
little more bandwidth than is necessary in some cases, but gives you
better cache locality (depending on how your comparisons are
organized).

> In the case of date_of_death, that property is actually on a different
> type than the birth which complicates things further.

Yes, it's a little unusual to have one end of the interval on one type
and the other on a different one.  My guess is that all people will
have eventually have a death date, cause of death, etc.

> I agree with you that if there was a standard way to encode a range
> then the query language (and filter UI) could do smarter things with
> ranges.
>
> Perhaps what we really need is a way of having the 'friendly'
> properties 'reach into' a more normative form which standardizes on
> time_interval.

So start_date becomes a proxy for time_interval->start?  That could be
useful.  I guess how important it is depends on whether you're
targeting users of the UI or app writers or ...  Application writers
probably aren't too worried about the extra level of indirection,
except with regards to backwards compatibilty for apps they've already
written.

Tom