It's an interesting reflection on the quality of machine-processible
data that we are generating as a community, if it's necessary to use
natural language processing or regular expressions to extract usable
date ranges from CMS [1] data. The advice to record earliest and latest
date in a consistent processible format has been around since the 1970s,
and remains in SPECTRUM to this day.
Of course, you still have to distinguish between duration of an event
and uncertainty over when exactly it happened. The CIDOC CRM SIG have
provided guidance on date recording [2] which aims to address this issue
as "ongoing throughout" vs. "at some time within". When looking into a
possible design pattern for dates in a Linked Data context [3], I found
that the W3C date types allow you to express less precise dates, e.g.
"year" [4]. This might be useful.
For places, there is in principle the option of using a bounding box or
boundary-line to indicate the size/scope of the place (which isn't quite
the same thing as imprecision, of course). Geonames has the former
(e.g. [5]); Ordnance Survey the latter [6], at least for administrative
units in the area it covers. Of course, having this information, and
getting to use it in an interactive context, are two different
challenges. Has anyone implemented boundary box or boundary-line-based
"pins", e.g. in OpenLayers?
One problem I am finding with geolocation is that when you convert
descriptive place name data to coordinates, every object from the "same"
place ends up with exactly the same coordinates. So to add to the
spurious precision of the place itself, you have a spurious collocation
of objects. I am trying to address this issue by generating a single
"pin" with a group description of the objects it contains, unless there
is only one. [7] (Apart from other considerations, popular web mapping
applications will often only display one pin for a single coordinate, so
one is rather forced into this approach.)
The requirement to display collections data on maps and in timelines is
possibly a useful wake-up call as regards the usefulness of our data.
Richard
[1] i.e. Collections Management System, not the other one
[2] http://www.cidoc-crm.org/docs/How_to%20implement%20CRM_Time_in%20RDF.pdf
[3] http://light.demon.co.uk/wordpress/?p=600 - all comments welcome, BTW
[4] http://www.w3.org/TR/xmlschema-2/#isoformats
[5] http://ws.geonames.org/get?geonameId=2644667
[6] http://data.ordnancesurvey.co.uk/datasets/os-linked-data/about
[7]
http://light.demon.co.uk/wordpress/?page_id=446&modes_query={Word%20search}=*{oakham}&page_id=537
On 04/11/2013 13:16, James Morley wrote:
> Hi David
>
> I've been looking at it from that angle too, thought not quite in as much
> detail as it sounds like you have! And I've also been thinking about the
> 'middle' bit that you allude to - once you've deciphered them, how you
> might store these things in a unified way.
>
> I'm working on a prototype crowdsourcing toolkit for cultural collections
> and will be presenting the concept in a quick open-mic session at next
> week's UKMW13. The aim is not just to give users tools, but also tap into
> natural language processing (e.g. OpenCalais, Alchemy, Zemanta) to suggest
> tags, locations, dates, people, events etc that users can then verify (or
> otherwise!).
>
> Give me a shout if you'd like to have a look at this in a day or two, when
> I should have something ready for testing.
>
> Cheers, James
>
>
> ---
> James Morley
> www.jamesmorley.net / @jamesinealing
> www.whatsthatpicture.com / @PhotosOfThePast
> www.apennypermile.com / @APennyPerMile
> <http://www.apennypermile.com>
>
>
> On Mon, Nov 4, 2013 at 11:54 AM, David Croft <[log in to unmask]>wrote:
>
>> I've been working on this problem on an off for a while now, but from the
>> other side as it were. Trying to extract the dates that the record author
>> meant from what they actually wrote.
>> There are a LOT of different date formats out there and I've yet to see a
>> really good solution.
>> I'm coming at this problem from a software angle, trying to decode dates
>> automatically, so my desires for date formats may be different to yours.
>> But I really, really, really wish that date information was stated
>> explicitly and consistently.
>>
>> Plenty of collections use modifiers like 'circa', 'early' or 'first half',
>> but then don't use these consistently.
>> In one record 'late 20th century' means 1950 to 2000, in another place it
>> will mean 1975 to 2000.
>> These sort of date modifiers never seem to get explicitly defined for the
>> collection which means that what one collection means by 'circa' is
>> different to what another collection means.
>> The modifiers also mean different things to different dates, 'circa 1950'
>> may mean 1945 to 1955 but is `circa 1950s' 1950 to 1959 or 1945 to 1965?
>> There are lots of records with dates like '80s' where you just have to
>> assume the century information or '1940-50s' where you assume it means 1940
>> to 1959.
>>
>> So for me, the best way is just to provide the upper and lower bounds for
>> date period in full, i.e. not `circa 1955' but instead `1950/1/1 to
>> 1959/12/31`.
>> Or if that's not possible, define exactly what you mean by 'circa',
>> 'late', 'early' etc and make that information available where anyone
>> looking at your records can see it.
>> For example, are you going to use the word 'circa'? or just put a 'c' on
>> the front of the date i.e. 'c1950'?
>> If there are two dates in a field does the circa apply to just the first
>> one or both? i.e. is 'circa 1950 to 1960' the same as 'circa 1950 to circa
>> 1960'?
>> If you are saying 'circa 19th century' do you mean up to 25 years either
>> side? 50 years? 75?
>> Software can decode any format you use as long as we know what the rules
>> are.
>>
>> P.S
>> There are some truly interesting date fields out there and I've been
>> keeping a list as part of my really tricky testing data.
>> Some of my favourites are '25 feb ?', 'circa pre world war two', 'early or
>> late 19th or 20 century' and 'c18-1 to c--01?'
>>
>> David
>>
>> ****************************************************************
>> website: http://museumscomputergroup.org.uk/
>> Twitter: http://www.twitter.com/ukmcg
>> Facebook: http://www.facebook.com/museumscomputergroup
>> [un]subscribe: http://museumscomputergroup.org.uk/email-list/
>> ****************************************************************
>>
> ****************************************************************
> website: http://museumscomputergroup.org.uk/
> Twitter: http://www.twitter.com/ukmcg
> Facebook: http://www.facebook.com/museumscomputergroup
> [un]subscribe: http://museumscomputergroup.org.uk/email-list/
> ****************************************************************
> .
>
--
*Richard Light*
****************************************************************
website: http://museumscomputergroup.org.uk/
Twitter: http://www.twitter.com/ukmcg
Facebook: http://www.facebook.com/museumscomputergroup
[un]subscribe: http://museumscomputergroup.org.uk/email-list/
****************************************************************
|