Re: suggestion of something like geoDate and geoDuration

About what you can use as "geological time" in the circa of Date or
Duration: yes, any syntactical representation is valid, because the
important in RDFa is the semantic, not the syntax. Of course, as
"scientific representation" you need some reference and control, the
suggestion of "translated time" (ex. 3.2kyr), so the value on, p. ex.
archgeoDuration, is not any, but "any that can be translated to a
acheological or geological valid time" (no astronomical unit as "3 light
year" p. ex.).

Please check the github's text suggestion,

     https://github.com/schemaorg/schemaorg/issues/242#issuecomment-76740565

(we can edit to a better decision making, here in the list) to get some
convergence of decisions.



2015-03-02 18:55 GMT-03:00 <Simon.Cox@csiro.au>:

>  A common convention is to use the two forms to distinguish between
> ‘amounts’ (which have just a unit) and ‘coordinates’ (which have a unit,
> origin and direction).
>
> For example “the Cretaceous period had a duration of 78 Ma, and ended at
> 66 Myr”.
>
>
>
> *From:* Peter Krauss [mailto:ppkrauss@gmail.com]
> *Sent:* Tuesday, 3 March 2015 3:45 AM
> *To:* Thad Guidry
> *Cc:* public-vocabs@w3c.org
> *Subject:* Re: suggestion of something like geoDate and geoDuration
>
>
>
> ok, it  was only a comment about the PDF that you cite, the PDF says,
>
>
>
> "Recommendation 1: Date. That geohistorical dates, (...) be expressed in
> years before the present by
>
>      the term 'annus', symbol ‘a’, with multiples symbolized as ‘ka’ ,‘Ma’
> , and ‘Ga’ ...
>
>
>
> "Recommendation 2: Duration. That quantities of geohistorical time derived
> from the rock record be expressed in years,
>
>    represented by the symbol ‘yr’, and multiples ‘kyr’, ‘Myr’, ‘Gyr’"
>
>
>
> So is "dual" because use two metric units. I suggest the duration ones.
>
> See
> https://github.com/schemaorg/schemaorg/issues/242#issuecomment-76740565
>
>
>
>
>
>
>
> 2015-03-02 12:57 GMT-03:00 Thad Guidry <thadguidry@gmail.com>:
>
>  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
> >>
> >>
> >
> >
>
>
>
>
>
>
>
>
>
>
>