Add OWL-Time and chronometric age extension guidance

ashepherd commented 4 years ago

See: https://geoschemas.org/extensions/temporal.html

Earthcube P419 added an extension field for describing Dataset temporal coverage in OWL-Time.

ashepherd commented 4 years ago

OWL-Time extensions are being pushed to production and onw is a good time to revisit our guidance on incorporating OWL-Time into schema.org guidance docs

@dr-shorthair do you know if the temporal aggregate work is getting released?

dr-shorthair commented 4 years ago

Its here https://w3c.github.io/sdw/time-aggregates/ but we have not yet initiated the formal publication of the TR. I'd been getting an earlier erratum in OWL-Time fixed. I believe that will complete this or next week at which point I'll trigger the process for aggregates and relations. Should take around a month from that point.

njarboe commented 4 years ago

I'm interested in doing some work on this issue and would like to see these timescales implemented so we can use them for our contributions at the Magnetics Information Consortium (MagIC) data repository. @fils I would like to make some changes and additions to: https://geoschemas.org/extensions/temporal.html

BP looks good.

MillionsOfYears should be MillionsOfYearsAgo to use the standard geologic phrasing (AGU journals and most others). I'm not sure why the "sameAs" resource listed does not describe it that way.

How I would revise: { "@id": "geosci-time:MillionsOfYearsAgo", "@type": ["time:TRS", "schema:Thing"], "schema:name": "Millions of Years Ago", "schema:alternateName": "Ma", "schema:sameAs": "http://resource.geosciml.org/classifier/cgi/geologicage/ma", "schema:description": "Temporal position expressed numerically scaled in millions of years increasing backwards relative to 1950. Calibration to 1950 usually not significant or done." }

I can/we should also add BillionsOfYearsAgo and ThousandsOfYearsAgo { "@id": "geosci-time:BillionsOfYearsAgo", "@type": ["time:TRS", "schema:Thing"], "schema:name": "Billions of Years Ago", "schema:alternateName": "Ga", "schema:description": "Temporal position expressed numerically scaled in billions of years increasing backwards relative to 1950. Calibration to 1950 usually not significant or performed." }

{ "@id": "geosci-time:ThousandsOfYearsAgo", "@type": ["time:TRS", "schema:Thing"], "schema:name": "Thousands of Years Ago", "schema:alternateName": "ka", "schema:description": "Temporal position expressed numerically scaled in thousands of years increasing backwards relative to 1950. Calibration to 1950 not always significant or done, except when carbon dating methods are used." }

njarboe commented 4 years ago

Here is an example of what we have implemented for time at MagIC for this data set:

I don't think that DateTime officially approves of large negative years, but I'm not sure if it is prohibited. That would really be the clearest and easiest way to add deep time.

"temporalCoverage": { "@type": "DateTime", "startDate": 1164, "endDate": -58051 }, "geosci-time": { "@type": "time:Instant", "time:inTimePosition": { "@type": "time:ProperInterval", "time:hasBeginning": { "time:hasTRS": { "@id": "geosci-time:BeforePresent" }, "time:numericPosition": { "@value": 786, "@type": "xsd:decimal" } }, "time:hasEnd": { "time:hasTRS": { "@id": "geosci-time:BeforePresent" }, "time:numericPosition": { "@value": 60000, "@type": "xsd:decimal" } } } },

nicholascar commented 4 years ago

@njarboe I'll add your three TRSes to this vocab of TRSes: http://linked.data.gov.au/def/trs. We are hoping that the OGC will pick up this TRS vocab (we are in negotiations) and re-issue it under an OGC namespace. Then these particular TRSes can be seen side-by-side with UNIX time, Gregorian etc.

Those vocab's entries are dual classes skos:Concept and time:TRS.

I will owl:sameAs back to your Named Individuals.

Are you and @ashepherd planning on maintaining http://schema.geoschemas.org/contexts/temporal# as a persistent namespace or would you be happy to settle for an OGC entries for these various TRSes if we preserved your properties?

njarboe commented 4 years ago

@nicholascar I'm not sure if http://schema.geoschemas.org/contexts/temporal# will be maintained. @ashepherd would have a better idea about that. I think including them in the TRS vocab is a good idea and I would be happy to have OGC entries for the TRSes, if you preserved our properties.

I changed "done" to "performed" in two of the three cases presented earlier for consistency (see below).

{ "@id": "geosci-time:MillionsOfYearsAgo", "@type": ["time:TRS", "schema:Thing"], "schema:name": "Millions of Years Ago", "schema:alternateName": "Ma", "schema:sameAs": "http://resource.geosciml.org/classifier/cgi/geologicage/ma", "schema:description": "Temporal position expressed numerically scaled in millions of years increasing backwards relative to 1950. Calibration to 1950 usually not significant or performed." }

I can/we should also add BillionsOfYearsAgo and ThousandsOfYearsAgo { "@id": "geosci-time:BillionsOfYearsAgo", "@type": ["time:TRS", "schema:Thing"], "schema:name": "Billions of Years Ago", "schema:alternateName": "Ga", "schema:description": "Temporal position expressed numerically scaled in billions of years increasing backwards relative to 1950. Calibration to 1950 usually not significant or performed." }

{ "@id": "geosci-time:ThousandsOfYearsAgo", "@type": ["time:TRS", "schema:Thing"], "schema:name": "Thousands of Years Ago", "schema:alternateName": "ka", "schema:description": "Temporal position expressed numerically scaled in thousands of years increasing backwards relative to 1950. Calibration to 1950 not always significant or performed, except when carbon dating methods are used." }

smrgeoinfo commented 4 years ago

other alternateNames that are in use: Mya, mybp, m.y.b.p.

nicholascar commented 4 years ago

OK, they are now in the TRS vocab, see http://linked.data.gov.au/def/trs (and Expand Before Present). We can indeed add in Mya, etc. as further alternateNames / altLabels.

Please feel free to contribute directly to the vocab with PRs against the source file at https://github.com/geological-survey-of-queensland/vocabularies/blob/master/vocabularies/trs.ttl. We can take any alternate properties in the RDF file (e.g. your schema.org v. the current SKOS) even if we don't display them in the UI instantly. For the moment there's only SKOS (see https://vocabs.gsq.digital/object?vocab_id=trs&uri=http%3A//linked.data.gov.au/def/trs%23ThousandsOfYearsAgo) but we can add a schema.org profile and reveal that since the display too, VocPrez, can display multiple profiles side-by-side.

njarboe commented 4 years ago

@nicholascar I have put in a pull request for another timescale commonly used in geology and archeology, BeforePresentCalibrated. I noticed a typo in the description on my pull request after I submitted it, but was not sure how to best fix it.

Also, with the new Before Present expansion list, the old Before Present timescale is now not displayed. Maybe it needs: skos:broader trs:BeforePresent ; added, but I was not sure about that, so did not put that in my pull request.

nicholascar commented 4 years ago

@njarboe where's the PR? I cant' see it! Happy to fix up typos etc. if you can show me where the PR it.

You can just keep pushing edits (commits) to the branch from which you are requesting the PR and the PR will just pick those up since PRs are between branches as whole, not branches at a fixed point in time. So you can easily fix up anything you want until the PR it merged. If you're using GitHub online, just click on the branch, as indicated at the top of the PR itself, and edit files there. If you're doing edits on your desktop then you should have the branch that the PR came from.

njarboe commented 4 years ago

@nicholascar I have not done a pull request before. Hopefully this time I did it right and you can see it. Let me know if I did anything wrong. Thanks.

nicholascar commented 4 years ago

Ah ha! Yes I see it at https://github.com/geological-survey-of-queensland/vocabularies/pull/220. Thanks!

fils commented 3 years ago

Adding a reference here to TDWG Issue:

Proposed Darwin Core Vocabulary Enhancement - ChronometricAge #15

nicholascar commented 3 years ago

other alternateNames that are in use: Mya, mybp, m.y.b.p.

Please note that QUDT now has a new MegaYR unit:

unit:MegaYR
    a qudt:Unit ;
    a qudt:DerivedUnit ;
    qudt:plainTextDescription "1,000,000-fold of the derived unit year." ;
    qudt:conversionMultiplier 31557600000000.0 ;
    qudt:hasDimensionVector qkdv:A0E0L0I0M0H0T1D0 ;
    qudt:hasQuantityKind quantitykind:Time ;
    qudt:informativeReference "https://en.wiktionary.org/wiki/megayear"^^xsd:anyURI ;
    qudt:isScalingOf unit:YR ;
    qudt:prefix <http://qudt.org/2.1/vocab/prefix/Mega> ;
    qudt:symbol "Myr" ;
    qudt:ucumCode "Ma"^^qudt:UCUMcs ;
    rdfs:isDefinedBy <http://qudt.org/2.1/vocab/unit> ;
    rdfs:label "Million Years"@en ;
    skos:altLabel "Mega Year"@en ;
    skos:altLabel "megannum"@la ;
    skos:altLabel "Ma" ;
.

This is present in the QUDT public repo now but isn't yet published through to the QUDT main web page.

ashepherd commented 3 years ago

Difficulty: Hard

positives

will address needs within our community
uses pre-existing vocabulary with a good track record

negatives

requires additional Linked Data resources and infrastructure to support hosting the extension. Cannot be supported by Github pages b/c of content negotiation (although not sure schema.org supports conneg anymore?)
unknown how many existing harvesters have a use case to harvest this proposed extension
would be our first extension to schema.org and its not a simple one.
https://schema.org/temporalCoverage now accepts a URL resource so we might re-think how to address this issue

Vote to exclude from v1.3

nicholascar commented 3 years ago

Cannot be supported by Github pages b/c of content negotiation

Actually this can be overcome: services like githack.com now support the addition of HTTP headers for things like RDF as well as their original offering of HYML rendering. We - Aust. Gov. - use this for GitHub-hosted static Linked Data resources such as ontologies. See https://linked.data.gov.au/def/agrif for an example.

ashepherd commented 3 years ago

@nicholascar thanks for dropping a note about githack.com. That's incredibly useful!

smrgeoinfo commented 3 years ago

Looks like githack.com is a one person mostly volunteer operation. Is Aus Gov supporting it?

adamml commented 3 years ago

@smrgeoinfo I was going to ask @nicholascar something similar - this in the FAQ caught my interest https://raw.githack.com/#no-uptime-guarantee compared to how it seems to be used in the linked.data.gov.au example

nicholascar commented 3 years ago

Looks like githack.com is a one person mostly volunteer operation. Is Aus Gov supporting it?

No, sot supported by us but used by us! It was set up after a previous, similar service was canned about 2 years ago.

We - Aust Gov - used to use our own hosting server for all small ontologies but we've prompted most ontology publishers to hose in GitHub or similar for free and to render out using GitHack. Large LD resources - large vocabs and datasets - are all hosted by systems but small, single document ontologies are using this approach.

I've not seen any GitHack errors in several years of service however we aren't seeing much load on our resource rendered through it.

If we ever did experience issues, we would either have to recommend a similar service, if one could be found, or put up a hosting server again, which I don't want to do if it can be avoided, or even replicate GitHack functionality ourselves as a service offering.

I think we are currently well served by GitHack for low load ontologies (most are!).

mbjones commented 3 years ago

More developments on the chronometric age metadata front. TDWG is finalizing extensions to DarwinCore to extend metadata for ChronometricAge (see https://tdwg.github.io/chrono/terms/). I think it would be helpful if we were aligned in science on schema.org. Here's an update from John Wieczorek, along with some links to their work.

The ChronometricAge Task Group (https://www.tdwg.org/community/esp/chrono/) has completed a round of public commentary for the Chronometric Age vocabulary extension to Darwin Core. During the course of the review, several amendments, clarifications and additions were recommended and implemented. The discussions and changes are documented (Github issues 15-24 at https://github.com/tdwg/chrono/issues?q=is%3Aissue+is%3Aopen+label%3A%22Process+-+under+public+review%22) and the results have been deployed to both the normative term list for the vocabulary (https://tdwg.github.io/chrono/list/) and its Quick Reference Guide (https://tdwg.github.io/chrono/terms/). The latter is the easiest way to assess the current state of the vocabulary, while the former provides the full history of the terms with all of their metadata.

The Task Group welcomes any further feedback now that these changes are in place. The continuation of the original 30-day period for public comment (beginning 2020-11-21) has been extended to 5 March 2021 to allow stakeholders to assess the updated Chronometric Age Extension and provide further recommendations if necessary. The purpose of the review is to allow the broadest possible community to see the proposed vocabulary in action and to assess whether it is sufficiently complete and clearly documented that it can provide a stable addition to the standards for sharing biodiversity data.

For this extended public commentary period, no update was made to the GBIF Chronometric Age Extension document. An update for that will be provided when the vocabulary has been ratified.

To view the proposal and/or engage in the review, visit https://github.com/tdwg/chrono/issues/15, which will provide further guidance and the means to comment. If you are unable or prefer not to submit comments via GitHub, you can send comments to the ChronometricAge Task Group convenor at gtuco.btuco@gmail.com. In the absence of objections or substantive amendment requests, the review will close on 2021-03-05."

On Sat, Nov 21, 2020 at 2:51 PM John Wieczorek tuco@berkeley.edu wrote:

The Darwin Core Maintenance Interest Group (https://www.tdwg.org/community/dwc/) is pleased to announce that the ChronometricAge Task Group (https://www.tdwg.org/community/esp/chrono/) of the Earth Sciences and Paleontology Interest Group (https://www.tdwg.org/community/esp/) has prepared a vocabulary enhancement for Darwin Core consisting of a ChronometricAge class and its properties. A minimum 30-day period for public comment is now open (2020-11-21). To view the proposal and/or engage in the review, visit https://github.com/tdwg/chrono/issues/15, which will provide further guidance and the means to comment. If you are unable to create GitHub comments, you can reply to this message or send comments to the ChronometricAge Task Group convenor at gtuco.btuco@gmail.com. In the absence of objections or substantive amendment requests, the review will close on 2020-12-21.

njarboe commented 3 years ago

The "ChronometricAge Extension to Darwin Core" https://tdwg.github.io/chrono/terms/ is quite comprehensive and looks very good through my geochronology eyes. The available terms cover everything we would need to describe MagIC's age metadata information. This is a good vocabulary to support and is part of an active, long lived organization. Thanks for pointing this out @mbjones. It seems like if we adopt this standard we could include it in v1.3. They are closing comments on the vocab on 5 March 2021.

mbjones commented 3 years ago

An update from John Wieczorek (@tucotuco):

On behalf of the ChronometricAge Extension Task Group, it is with great pleasure and a sigh of relief to announce the finalization of the ChronometricAge Extension to Darwin Core and closure of the Task Group. Everything, including the normative term list document (https://tdwg.github.io/chrono/list/), Quick Reference Guide (https://tdwg.github.io/chrono/terms/), and GBIF extension (https://tools.gbif.org/dwca-validator/extension.do?id=http://rs.tdwg.org/chrono/terms/ChronometricAge) is now in production. The latter is available for immediate use in Darwin Core Archives, and can be mapped in any instance of the Integrated Publishing Toolkit that is enabled to use the extension.

mbjones commented 3 years ago

Call on 2021-06-24: Decided to endorse the Darwin Core approach.

TODO:

[x] review DwC chronometric age proposal versus the OWL-Time approach
[x] write Dataset.md guidelines on representing time and geo time

njarboe commented 3 years ago

Doug and I looked over the the Darwin Core documentation in detail and while it does have a schema for describing chronometric ages in detail (great), it does not point to or present vocabulary lists to use for the schema values. We believe that geologic time is a crucial topic to have in schema.org, but don't want to promote a standard that is inadequate that becomes widely accepted. On the other hand, people need to put geologic age in there schema.org headers right now and will thus be doing it ad-hoc if we have no recommendations at all. A simple example using variableMeasured but not part of the endorsed guidelines perhaps? I think we should discuss this at the meeting on Tuesday.

dr-shorthair commented 3 years ago

A linked-data representation of the chronostratigraphic chart (geological timescale) is available from https://vocabs.ardc.edu.au/viewById/196 Individual periods (all ranks) have URIs like http://resource.geosciml.org/classifier/ics/ischart/Tortonian They include OWL-Time properties.

The source is at https://github.com/CGI-IUGS/timescale-data

nicholascar commented 3 years ago

The data @dr-shorthair refers to above will eventually - this calendar year - be delivered online at https://stratigraphy.org/chart somewhere, as well as its current location, as the ICS comes to take scientific oversight of the data: it's becoming official as the ICS' source of truth, rather than the image charts which will eventually be generated from the semantic data.

smrgeoinfo commented 3 years ago

I have pored through the discussions and the existing schemes I could find, and generated a draft decision document for discussion. Its in a new branch for Issue77 on github. There is a JSON-LD example doc in examples that has all the example code that's in the draft decision doc.

main points in the decision doc:

use http://www.w3.org/2006/time#hasTime property from W3C OWL Time (Cox and Little, 2021-06-29 editors draft) to document temporalCoverages that can not be expressed using schema:DateTime
Provide numeric age positions in Ma before 1950 if possible
If age is specified based on a time scale, provide nearest subsuming age from the International Chronostratigraphic Chart
use schema:temporalCoverage text value to provide a human-user-friendly statement of the temporal coverage.

ashepherd commented 3 years ago

ah, nice find, @smrgeoinfo!!

njarboe commented 3 years ago

@smrgeoinfo, the draft doc is looks good.

The http://www.w3.org/2006/time/hasTime link does not resolve and I think should be https://www.w3.org/TR/owl-time/#time:hasTime

hasBeginning and hasEnd, schema.geoschemas.org for numeric ages, and stratigraphy.org for the named geologic timescale seem like a sufficient minimal set of terms so that we should add this to 1.3 for ESIP endorsement.

ashepherd commented 3 years ago

To-DO (ESIP Summer Meeting):

1) Nick is in agreement with @smrgeoinfo design docs

2) Needs Pull Request

3) Uncertainty would be useful, but maybe not necessary for discovery - Nick

4) Future focus: being able to specify which time scale

dr-shorthair commented 3 years ago

http://www.w3.org/2006/time/has Time does not resolve

OWL-Time uses a # name space. Try http://www.w3.org/2006/time#hasTime which does resolve

smrgeoinfo commented 3 years ago

URI for hasTime fixed.

ashepherd commented 2 years ago

@njarboe could you review the ADR for temporal coverage in the develop branch: https://github.com/ESIPFed/science-on-schema.org/blob/develop/decisions/77-temporalCoverageGuidance.md

[ ] Is the ADR reflecting our decisions (change status to Accepted)
[ ] Do our guidelines reflect the ADR decisions

mbjones commented 2 years ago

Reviewed at 2022-02-07 SOSO meeting, agreed that we still need to merge decisions and examples from the ADR into the main Dataset guide document.

[ ] Merge decisions text and examples into Dataset.md guide document

njarboe commented 2 years ago

While working on the merging the decisions and examples I had a few questions:

Why is the capitalization of terms not consistent. Some start with a capital letter and others don't? "time:hasTime": { "@type": "time:Interval", "time:hasBeginning": { "@type": "time:Instant", "time:inTimePosition": { "@type": "time:TimePosition",

Is xsd a default context or should it be specified in the context? Current context is: "@context": { "@vocab": "http://schema.org/", "time": "http://www.w3.org/2006/time#", "gstime": "http://schema.geoschemas.org/contexts/temporal#", "ts": "http://resource.geosciml.org/vocabulary/timescale/", "icsc": "http://resource.geosciml.org/clashttps://vocabs.ardc.edu.au/repository/api/lda/csiro/international-chronostratigraphic-chart/geologic-time-scale-2020/resource?uri=http://resource.geosciml.org/classifier/ics/ischart/Boundariessifier/ics/ischart/" },

Where are validators to test the .json and the schema.org text?

Do we need the geologic time units for the uncertainty at the higher level? "time:inTimePosition": { "@type": "time:TimePosition", "time:hasTRS": {"@id": "gstime:BeforePresentCalibrated"}, "time:numericPosition": { "@value": 2460, "@type": "xsd:decimal" }, "geosci-time:GeologicTimeUnitAbbreviation": { "@value": "BP-CAL, "@type": "xsd:string" } } "gstime:UncertaintyOlder": { "value": 130, "@type": "xsd:decimal"}

dr-shorthair commented 2 years ago

Why is the capitalization of terms not consistent. Some start with a capital letter and others don't?

Classes (Types) are UpperCamelCase, propertynames (predicates) are lowerCamelCase - this is conventional, going back through many systems.

mbjones commented 2 years ago

After discussion today on the SOSO call, it surfaced that @njarboe still has a pull request for the issues described above needed to complete migration of the OWL-time guidelines into develop. Moved this back into InProgress while we await that PR to be created and merged.

njarboe commented 2 years ago

@dr-shorthair I am reading through your Time Ontology in OWL, Draft 21 April 2022. I did not seem to be able to find this document earlier when working on this project. I see that the :hasTime property "only was included for users unwilling or unable to define their own semantics" I'm not sure what that means exactly but our documentation is using :hasTime in this example:

{   "@type": "Dataset",
    "description": "Temporal position expressed numerically scaled in millions of years increasing backwards relative to 1950. To specify a Geologic Time Scale, we use an OWL Time Instant. The example below specifies 760,000 years (0.760 Ma) before present",
{    "@context": {
        "@vocab": "http://schema.org/",
        "time": "http://www.w3.org/2006/time#",
        "gstime": "http://schema.geoschemas.org/contexts/temporal#",
    },
    "temporalCoverage": "Eruption of Bishop Tuff, about 760,000 years ago",
    "time:hasTime": {
        "@type": "time:Instant",
        "time:inTimePosition": {
            "@type": "time:TimePosition",
            "time:hasTRS": {"@id": "gstime:MillionsOfYears"},
            "time:numericPosition": {
                "@value": 0.760,
                "@type": "xsd:decimal"
            }  }  }   }

Can we eliminate it by writing it like this?

{    "@context": {
        "@vocab": "http://schema.org/",
        "time": "http://www.w3.org/2006/time#",
        "gstime": "http://schema.geoschemas.org/contexts/temporal#",
    },
    "temporalCoverage": "Eruption of Bishop Tuff, about 760,000 years ago",
     "time:inTimePosition": {
          "@type": "time:TimePosition",
          "time:hasTRS": {"@id": "gstime:MillionsOfYears"},
          "time:numericPosition": {
              "@value": 0.760,
              "@type": "xsd:decimal"
            }  }  }   }

I am still studying the Time Ontology in OWL Draft. It would be great to talk to you sometime about how to deal with uncertainties in time positions. I'd like to add that to the next version of the SOSO guidelines, if it makes sense to do so. I work with paleomagnetic and radiometric dating of rocks and am interested in the accuracy of dates and the process of converting older timescales/ages to newer ones.

dr-shorthair commented 2 years ago

@njarboe I apologise I don't read JSON very easily. So I'm not quite clear about the semantics here. And both fragments appear to be incomplete as the {braces} don't balance.

Is the intention to describe a dataset, or an event?

Is the value of temporalCoverage intended to sit alongside the numeric value expressed using the time: elements, or is the text an annotation of the numeric value?

smrgeoinfo commented 2 years ago

Tricky set of triples here... expected range of temporal coverage is DateTime (irrelevant here..), Text (what we have) or URL (link to what??? typical schema.org ambiguity...) Subject of inTimePosition as constructed would be the dataset, but obviously that's not what we want. Its a short cut. What we want is (schematically) dataset > about > event > inTimePosition. The eruption of the tuff is an event (perdurant) that has a timePosition. The operational problem is whether users can handle the semantically precise but verbose linkages...
I guess the precise solution would be for the temporalCoverage value to be a URI that links to a time:TimePosition for the eruption that is the subject of the dataset?

njarboe commented 2 years ago

"I guess the precise solution would be for the temporalCoverage value to be a URI that links to a time:TimePosition for the eruption that is the subject of the dataset?"

I think this a good solution but we probably don't have time to figure this out for the 1.3 release. I've been holding up the release with trying to get the geologic time in and we can add the link format later. Here is what we decided to do yesterday that eliminates the undesirable hasTime property:

"@type": "Dataset",
    "description": "Eruptive activity at Mt. St. Helens, Washington, March 1980 - January 1981; temporal coverage expressed as range of dateTime",
    "temporalCoverage": ["1980-03-27T19:36:00/1981-01-03T00:00:00Z",
        {
            "time:hasBeginning": {
            "@type": "time:Instant",
            "time:inXSDDateTimeStamp": "1980-03-27T19:36:00Z"
        },
            "time:hasEnd": {
                 "@type": "time:Instant",
                 "time:inXSDDateTimeStamp": "1981-01-03T00:00:00Z"
            }
         }]

I'll update the docs and get the pull request in.

smrgeoinfo commented 2 years ago

Following that pattern, geologic ages could look like this

{
  "@context": [
      "https://schema.org/",
      {"time": "http://www.w3.org/2006/time#"}],
    "@type": "Dataset",
   "temporalCoverage": {
        "@type": "time:ProperInterval",
        "time:hasBeginning": {
            "@type": "time:Instant",
            "time:inTimePosition": {
                "@type": "time:TimePosition",
                "time:hasTRS": {"@id": "http://www.opengis.net/def/crs/OGC/0/ChronometricGeologicTime"},
                "time:numericPosition": 4000
            }
        },
        "time:hasEnd": {
            "@type": "time:Instant",
            "time:inTimePosition": {
                "@type": "time:TimePosition",
                "time:hasTRS": {"@id": "http://www.opengis.net/def/crs/OGC/0/ChronometricGeologicTime"},
                "time:numericPosition": 2800
            }
        }
    }
}

njarboe commented 2 years ago

@smrgeoinfo @adamml I'm having trouble with GitHub at the moment. Sometimes it's working an other times not. Maybe something to do with the anti-bot system. I have attached my work on the examples temporalCoverage.jsonld.naj.txt. I'll try to get the docs updated as soon as possible, but if I am still stuck by Wednesday evening, maybe someone else can update the the temporalCovarage.jsonld and adjust my credit appropriately.

mbjones commented 2 years ago

Done and merged into develop.

smrgeoinfo commented 1 year ago

☹ sad…

The time instants are calendar dates, not geologic time. It seems we need to ‘break’ schema.org to put an optional time:TemporalEntity in as the value for Temporal coverage. That would allow instants or intervals. Intervals can have beginning and end that are inTimePosition ( https://www.w3.org/TR/owl-time/#time-position https://www.w3.org/TR/owl-time/#time-position).

Stephen M. Richard

US Geoscience Information Network (USGIN)

@.> @.

520-869-8545

From: njarboe @.> Sent: Tuesday, May 3, 2022 7:49 AM To: ESIPFed/science-on-schema.org @.> Cc: Stephen Richard @.>; Mention @.> Subject: Re: [ESIPFed/science-on-schema.org] Add OWL-Time and chronometric age extension guidance (#77)

"I guess the precise solution would be for the temporalCoverage value to be a URI that links to a time:TimePosition for the eruption that is the subject of the dataset?"

I think this a good solution but we probably don't have time to figure this out for the 1.3 release. I've been holding up the release with trying to get the geologic time in and we can add the link format later. Here is what we decided to do yesterday that eliminates the undesirable hasTime property: { @. https://github.com/type ": "Dataset", "description": "Eruptive activity at Mt. St. Helens, Washington, March 1980 - January 1981; temporal coverage expressed as range of dateTime", "temporalCoverage": ["1980-03-27T19:36:00/1981-01-03T00:00:00Z", { "time:hasBeginning": { @. https://github.com/type ": "time:Instant", "time:inXSDDateTimeStamp": "1980-03-27T19:36:00Z" }, "time:hasEnd": { @.*** https://github.com/type ": "time:Instant", "time:inXSDDateTimeStamp": "1981-01-03T00:00:00Z" } }]

I'll update the docs and get the pull request in.

— Reply to this email directly, view it on GitHub https://github.com/ESIPFed/science-on-schema.org/issues/77#issuecomment-1116189315 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD5KZAYM5HGGNJUEVN2TSLVIE4FRANCNFSM4KG4WG4A . You are receiving this because you were mentioned.Message ID: @.***>

njarboe commented 1 year ago

@smrgeoinfo Looking at the https://www.w3.org/TR/owl-time documentation it seems to me that a time:Instant can be used with any timescale (calendar dates or geologic), but I should have used inTemporalPosition instead of inTimePosition for the correct referencing of a geologic timescale. Also, I may not understand exactly how to use the diagrams in the OWL documentation to create the schema.org format. I would appreciate being able to discuss this issue with you (Zoom call?) or we could discuss in the next Science-on-Schema.org meeting next week on Oct 27th.

It is sad ☹ that I didn't get this right. Hopefully it can be fixed and does not cause too many problems for people.

njarboe commented 1 year ago

@smrgeoinfo We discussed this issue some at the SOSO meeting this month. It seems to me/us now that the current guidelines are consistent with the OWL Time spec.

In the diagram below you can see that "Instant" can contain a inTimePosition : TimePosition

And that a TimePosition does not have to be a date:time. It can be a decimal position or named position(string) in a timescale specified by TRS (see below). Let me know what you think. We have put this issue on the agenda for the next SOSO meeting (date to be determined due to Thanksgiving) if you would like to discuss it in person then.

smrgeoinfo commented 1 year ago

TimePosition looks good to me

Stephen M. Richard

US Geoscience Information Network (USGIN)

@.> @.

520-869-8545

From: Nicholas Jarboe @.> Sent: Thursday, October 27, 2022 12:43 PM To: ESIPFed/science-on-schema.org @.> Cc: Stephen Richard @.>; Mention @.> Subject: Re: [ESIPFed/science-on-schema.org] Add OWL-Time and chronometric age extension guidance (#77)

@smrgeoinfo https://github.com/smrgeoinfo We discussed this issue some at the SOSO meeting this month. It seems to me/us now that the current guidelines are consistent with the OWL Time https://www.w3.org/TR/owl-time spec.

In the diagram below you can see that "Instant" can contain a inTimePosition : TimePosition https://user-images.githubusercontent.com/1278789/198382350-690a4967-275b-408d-ba65-f2e7cbc7e61f.png

And that a TimePosition does not have to be a date:time. It can be a decimal position or named position(string) in a timescale specified by TRS (see below). Let me know what you think. We have put this issue on the agenda for the next SOSO meeting (date to be determined due to Thanksgiving) if you would like to discuss it in person then.

https://user-images.githubusercontent.com/1278789/198382708-d0a45174-70cd-40e0-9b4c-fcd9f94af4bd.png

— Reply to this email directly, view it on GitHub https://github.com/ESIPFed/science-on-schema.org/issues/77#issuecomment-1293985255 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD5KZHO5QDQBABG337IXVLWFLLNRANCNFSM4KG4WG4A . You are receiving this because you were mentioned. https://github.com/notifications/beacon/AAD5KZCL5YRBZ4BZJ2UYQSDWFLLNRA5CNFSM4KG4WG4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOJUQKLZY.gif Message ID: @. @.> >

ESIPFed / science-on-schema.org

Add OWL-Time and chronometric age extension guidance #77

positives

negatives