RE: Circa. dates

Also note that as soon as you get into 'named' time periods, then you have to tangle with non-Gregorian calendars. 
ISO 8601 only deals with Gregorian dates. XML Schema (and, transitively, OWL-Time) inherit this limitation. 

This doesn't work for many situations, not only geologic time and pre-historic time, but also non-Gregorian calendars used currently in some communities (Hebrew, Arabic, Baha'i calendars). 

And then there are coordinate systems, like Unix time and Loran-C, which express time with a number on a line with a direction and origin. 

See http://semantic-web-journal.net/content/time-ontology-extended-non-gregorian-calendar-applications-0 for a longer discussion, along with proposed solutions for OWL applications. 


-----Original Message-----
From: Dave Caroline [mailto:dave.thearchivist@gmail.com] 
Sent: Sunday, 1 March 2015 5:23 AM
To: Wallis,Richard
Cc: public-vocabs@w3c.org
Subject: 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 Sunday, 1 March 2015 22:12:45 UTC