Re: Circa. dates

It gets worse, dates have bugged me for a long time
a few examples one sees
circa 300BC
Jurassic period
Caroline period http://en.wikipedia.org/wiki/Caroline_era
16th century

Database designers seem to have dodged the issue

Dave Caroline (name not related to the period I think)


On 28/02/2015, Wallis,Richard <Richard.Wallis@oclc.org> wrote:
> Hi all,
>
> With colleagues I have been looking at how we might handle historical
> approximate dates in Schema.org<http://Schema.org>.  The initial requirement
> being to be able to describe an old book or manuscript published say in
> approximately 1765.  A common need in the bibliographic world, with the
> normal string based solution being "circa. 1765", or "c. 1765" - Wikipedia
> providing some examples<http://en.wikipedia.org/wiki/Circa>.
>
> The knee-jerk reaction was to suggest some sort of approximateDateCreated
> property for CreativeWork which would not only help us bibliographic folks
> but also those in museums and galleries with similar date approximation
> needs.
>
> Broadening the analysis it became clear that this need could be applicable
> in most any case where you would expect a Date<http://schema.org/Date> in
> the range of a property.  birthDate, deathDate, dateCreated, datePublished,
> foundingDate, all being all potential candidates for Circa style dates.
> Rolling things into the future you could imagine other examples such as
> wanting to describe the last serviced date of a vehicle being circa 2013.
>
> So how to solve this in a simple, yet generic, way?
>
> We could take advantage of the default "if you haven't got a specified type
> for a property, a Text is acceptable" pattern in Schema, and just put in a
> text string with a defined format: "c.1765".
>
> Perhaps a more appropriate solution would be to define a new data type, to
> be added to the range of suitable properties.
>
> My pragmatic (KISS and don't break stuff) view of this leads me to suggest a
> new data type named 'circaData', or maybe 'approximateDate' as a subType of
> Date.  With descriptive information in the Type definition explaining
> why/how you would use it in the use cases I describe above.
>
> This approach would add this important functionality, for those describing
> old stuff, without the need for major upheaval across the vocabulary, and
> would at least default to a date for those that do not care or look for such
> approximation aspect of dates.
>
> ~Richard
>
>

Received on Saturday, 28 February 2015 18:23:06 UTC