[Data-modeling] Historical currency

Ed Laurent spatial.db at gmail.com
Wed Apr 2 06:26:08 UTC 2008


What if you had the information in hand for dates that a currency was used?
For example, you conducted a detailed historical investigation into these
dates because you were interested in the rise and fall of  Roman currency or
the US$ over a percentage of the world's population in relationship to Roman
or US defense spending as a percentage of GDP? Not a common question but not
out of the question. Also, other people may want to make use of that
information for other purposes.

I see how it would be useful to maintain a binary "current currency?"
property if the date data were not always available. However, users should
be able to store the more precise information if available. Can we keep both
sets of properties, and perhaps automatically turn the "Current?" property
to no if an end date is set? There is some redundancy here but both versions
of the data have utility.

-Ed


On Tue, Apr 1, 2008 at 7:36 PM, Jeff Prucher <jeff at metaweb.com> wrote:

>
>
> > -----Original Message-----
> > From: data-modeling-bounces at freebase.com
> > [mailto:data-modeling-bounces at freebase.com] On Behalf Of Jeff Thompson
> > Sent: Monday, March 31, 2008 11:59 PM
> > To: Freebase data modeling mailing list
> > Subject: Re: [Data-modeling] Historical currency
> >
> > Christopher R. Maden wrote:
> > > we should be
> > > able to capture the distinction without overcomplicating
> > the model -
> > > or indeed without knowing the dates involved. This last point is a
> > > problem with time-valued properties; if I know that
> > something was true
> > > in the past but I don't know *when* it stopped being true,
> > I can either lie (excuse me, "guess" - er, "estimate") or
> > make an assertion that appears to be currently true; neither is ideal.
> >
> > The problem assumes a property can only be true over one
> > continuous time span.  But think of a country occupied by the
> > Romans, then beaten back, then occupied again, then finally
> > defeated.  What is time-value for the property that says the
> > country has Roman currency?  Time-valued properties need to
> > allow for multiple periods.  So in your case above, if you
> > know that something was true in the past, even for a day,
> > then assert that period.  If someone else can show that it
> > was true for some period after that, then that period of
> > validity can be added too.
>
> I don't think Chris was suggesting that a time-valued currency property
> would be unique. The problem is not with representing values that change
> over time, even if they change back and forth; that's very simple and
> implicit in most time-valued properties I can think of (Grover Cleveland's
> two non-contiguous terms as U.S. President are an example of this that I
> know is in the graph). The problem is making assertions about data for
> which
> we have no time-value information but which is modeled as being
> time-valued.
> So it's one thing to say a country had Roman currency from M to N, then
> its
> own currency from O to P, then Roman again from Q to R, and then its own
> currency starting again at S. This is good, clear data. It's another thing
> entirely to say that a country has or had Roman currency and its own
> currency; without dates, you have no way of knowing which (if any) is the
> current currency and which are historical. Since this is the quality of
> data
> that we currently have (i.e., I think Chris is trying to avoid this issue
> by
> making the properties binary. So we can assert that certain currencies are
> current, and that certain currencies have been used at a time or times in
> the past but are no longer used.
>
>
>
> Jeff Prucher
>
>
> _______________________________________________
> Data-modeling mailing list
> Data-modeling at freebase.com
> http://lists.freebase.com/mailman/listinfo/data-modeling
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freebase.com/pipermail/data-modeling/attachments/20080402/d2fb85d2/attachment.htm 


More information about the Data-modeling mailing list