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-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 Monday, 2 March 2015 07:48:40 UTC