suggestion of something like geoDate and geoDuration

About "Palo and Geo contexts" explained by Thad Guidry and others,
in the topic "Circa. dates" (for "publishing date" in
bibliographies/reference lists)
   (see attached email thread)
... I understand that the topic here is a new topic, that can be isolated
and
more objectively discussed.
It is a suggestion, to create new properties, something like

  geoDate       = geological date (X giga-years ago)
  geoDuration  = geological duration (X kilo-years)

so, I created this new topic in the list. Sorry if was wrong my
interpretation.

- - - - -

About the Guidry's cited article (40890_articles_article_file_1641.pdf
<http://www.agiweb.org/nacsn/40890_articles_article_file_1641.pdf>), that
use different units for date and duration, I think is better to use the
same "geoTime units" for both, see
   http://www.geosociety.org/TimeUnits/


2015-03-02 11:42 GMT-03:00 Thad Guidry <thadguidry@gmail.com>:

> I agree with the authors
> of this paper where SI is compared and Palo and Geo contexts are taken
> into account.  The need for
> separate
> date structures for the Sciences is clearly stated.
> http://www.agiweb.org/nacsn/40890_articles_article_file_1641.pdf
>
> Thad
> +ThadGuidry <https://www.google.com/+ThadGuidry>
>
> On Mon, Mar 2, 2015 at 2:19 AM, <Simon.Cox@csiro.au> wrote:
>
>> 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
>> >>
>> >>
>> >
>> >
>>
>>
>