Re: suggestion of something like geoDate and geoDuration

I should have further stated that we currently capture Periods, Eons,
Categories of Time and Date with another specific type....
http://schema.org/Event

And for the Sciences, I think
​ ​
it makes sense to
​ ​
start at Event and work down from there with any further suggestions.

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

On Mon, Mar 2, 2015 at 9:51 AM, Thad Guidry <thadguidry@gmail.com> wrote:

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