Re: suggestion of something like geoDate and geoDuration

Add at https://github.com/schemaorg/schemaorg/issues/242

Less informal *suggestion for a v1.2 specializatin proposal*:

   -

   Unify archeological, geological, etc. sciences. All can use non-usual
   dates. Example: "5th millennium BC" is non-usual, "3rd eon" is non-usual.
   -

   elect a generic prefix for new labels. Example: "archgeo", for
   archgeoDate and archgeoDuration.
   - the syntax of values is non-controlled. As "scientific
   representation", the only control is the principle of "valid translated
   time". Example: "3200 years" can be translated to "3.2kyr", is valid; "3000
   light years" is not valid.


... or, perhaps we can include all "long long time" (non-usuals) of
scientifically valid dates and durations, in only one "lonlong"
specialization, so generic  *LonglongDate* and *LonglongDuration*.  ;-)



2015-03-03 7:30 GMT-03:00 Peter Krauss <ppkrauss@gmail.com>:

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