> -----Original Message-----
> From: Museums Computer Group [mailto:[log in to unmask]] On Behalf Of
> Michael Selway
> Sent: 02 October 2009 10:17
> To: [log in to unmask]
> Subject: BC dates
>
> Tom Jenkins writes:
> > Just wondering if anyone knew if there was an accepted standard way
> of
> > storing BC dates in collection databases so they're searchable
> online.
> > Putting negative dates seems the most obvious to me, but perhaps
> this is
> > frowned upon... I know the British Museum have BC objects online;
> anyone
> > there or anywhere else care to share their thoughts?
>
> Hi Tom,
>
> It depends on how the collection database makes it out to the
> on-line site: to do effective date searching, the web site search
> mechanics you're using will need to understand the dates attached
> to your objects. So you'll need a search engine which understands
> BC dates, and then you'll also need to load the BC dates in quite
> explicitly. "Negative dates" sounds appealing, but there's no
> certainty anywhere that this will be effective: indeed you'd hope
> any collection database would refuse to accept "-15/03/0057"
> becuase it's just odd and at best ambiguous, whereas "57 BC" is
> clear.
Ah yes, I forgot to mention that our data is stored as start year/end
year; on 99.99% of our records the only data available is the year or
year range. Thus our data will essentially be in the form of start year
and end year, so that's why I considered negativity. I should have said
that we plan to be feeding into CultureGrid, which means the data will
be going out to other websites for use... most of which I'm guessing
won't understand 57BC etc.
>
> The British Museum catalogue their collection using MUSIMS (now
> called MuseumIndex+). MuseumIndex+ has specific support for BC
> dates, as well as other things such as circa dates, ranges,
> periods ("pre-neolithic", "renaissance", etc), and so on. I can
> let you into a little trade secret here: MuseumIndex+ stores BC
> dates *internally* as negative numbers. But at all interfaces -
> user interfaces and machine interfaces (APIs + protocols) - they
> are proper BC dates.
We're on CALM at the moment, so we have similar functionality; however,
this isn't really ideal when exporting to a different database (we are
migrating) as the fields are just spat out as plain text. Rather than
write a lookup table for all the weird and wonderful ways dates have
been entered over the years (try 'Circa early 1900 - Late 20th Century')
I spent most of yesterday replacing the 'concept' dates with numerical
year ranges. So yeah, our fields are integers rather than datestamps.
I'm told that this is acceptable for CultureGrid, and if not it's
trivial to do some post-processing. I'm not in charge of the migration,
so I'm not sure what we're moving to, but perhaps it can do the same
trick as MuseumIndex+ that you mentioned. Many thanks for your advice!
>
> Best regards,
> Michael.
>
> ****************************************************************
> For mcg information visit the mcg website at
> http://www.museumscomputergroup.org.uk
> To manage your subscription to this email list visit
> http://www.museumscomputergroup.org.uk/email.shtml
> ****************************************************************
------------------------------------------------------------------------------
DISCLAIMER: This email and files transmitted are
confidential and are intended solely for the use of the
intended recipient. If you are not the intended
recipient, or the person responsible for delivering it to
the intended recipient, you may not copy, disclose,
distribute or use it in any unauthorised manner. If you
have received this email in error please notify us by
email to [log in to unmask] and then delete
it and any attachments accompanying it. Please note that
Wolverhampton City Council cannot guarantee that this
message or any attachments are virus free or have not been
intercepted and amended.
Any views or opinions expressed within this email are
those of the author and may not necessarily reflect those
of Wolverhampton City Council and no contractual
arrangement is intended to arise from this communication.
==============================================================================
****************************************************************
For mcg information visit the mcg website at
http://www.museumscomputergroup.org.uk
To manage your subscription to this email list visit
http://www.museumscomputergroup.org.uk/email.shtml
****************************************************************
|