Add OWL-Time and chronometric age extension guidance

[ashepherd]

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

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

[ashepherd]

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]

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]

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]

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]

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

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

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

[nicholascar]

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]

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

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

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

Ah ha! Yes I see it at geological-survey-of-queensland/vocabularies#220. Thanks!

[fils]

Adding a reference here to TDWG Issue:

Proposed Darwin Core Vocabulary Enhancement - ChronometricAge #15

[nicholascar]

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]

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]

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]

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

[smrgeoinfo]

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

[adamml]

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

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]

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 tdwg/chrono#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 [email protected]. 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 [email protected] 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 tdwg/chrono#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 [email protected]. In the absence of objections or substantive amendment requests, the review will close on 2020-12-21.

[njarboe]

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.

[smrgeoinfo]

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:

1. 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
2. Provide numeric age positions in Ma before 1950 if possible
3. If age is specified based on a time scale, provide nearest subsuming age from the International Chronostratigraphic Chart
4. use schema:temporalCoverage text value to provide a human-user-friendly statement of the temporal coverage.

[ashepherd]

ah, nice find, @smrgeoinfo!!

[njarboe]

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

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]

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]

URI for hasTime fixed.

[ashepherd]

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

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]

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]

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]

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]

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

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

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]

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

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]

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

Done and merged into develop.

[smrgeoinfo]

☹ 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 <#77 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD5KZAYM5HGGNJUEVN2TSLVIE4FRANCNFSM4KG4WG4A> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[njarboe]

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

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

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 <#77 (comment)> , 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: ***@***.*** ***@***.***> >