RE: Circa. dates

However, the geological timescale is hierarchical. 
For the named periods there is an ordering within each 'rank', but the ranks are nested. [1] [2] 
So a single sort order doesn't work for named periods if they are of different ranks. 
And at the finest scales, the scale is defined on a per region or locality basis. 

Only the boundaries form a single sequence, and the periods are defined in terms of the boundaries that define their beginning and end. 
So it is actually more like a constrained topology. 

[1] http://dx.doi.org/10.1130/GES00022.1 
[2] http://stratigraphy.org/index.php/ics-chart-timescale 

-----Original Message-----
From: Dave Caroline [mailto:dave.thearchivist@gmail.com] 
Sent: Monday, 2 March 2015 6:48 PM
To: Cox, Simon (L&W, Highett)
Cc: Richard.Wallis@oclc.org; public-vocabs@w3c.org
Subject: Re: Circa. dates

The mixing of fuzzy and textual and numeric dates makes me think of a similar problem in sorting text which is solved by collation(sorting
rule) in a database.
http://stackoverflow.com/questions/341273/what-does-character-set-and-collation-mean-exactly

I think dates classified this way would become easy to search, sort and intermingle expressions of dates

Dave Caroline

On 01/03/2015, Simon.Cox@csiro.au <Simon.Cox@csiro.au> wrote:
> 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-gre
> gorian-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 Monday, 2 March 2015 08:20:23 UTC