Re: suggestion of something like geoDate and geoDuration

To be clear, I am not FOR dual time units.  I want only 1 representation of
time(with many properties as needed).  Where that time can be given
multiple categorizations of Eons, Periods,
​
whatever, etc.  Time and Date in our current schema just needs a little
more love and properties under them to enable that and Approximate, i.e.
Circa.

I was simply relaying the fact that the Sciences have a need for
partitioning startDate's and endDate's without being explicit with them.

To me, time is absolute.  Humans just want/need more context and words and
symbols to categorize particular startDate's and endDate's ...
without explicitly saying or giving the startDate and endDate...because it
is implied, such as Miocene.


Thad
+ThadGuidry <https://www.google.com/+ThadGuidry>

On Mon, Mar 2, 2015 at 9:15 AM, Peter Krauss <ppkrauss@gmail.com> wrote:

> 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
>>> >>
>>> >>
>>> >
>>> >
>>>
>>>
>>
>