Wuchiapingian definition #3

hmuniz · 2019-07-18T18:00:39Z

geosciml.org/resource/static/vocabulary/timescale/isc2018-1.ttl

Lines 13898 to 13941 in 0c32100

    
           isc:Wuchiapingian 
        
             a gts:Age ; 
        
             a gts:GeochronologicEra ; 
        
             a skos:Concept ; 
        
             a time:ProperInterval ; 
        
             rdfs:comment "older bound -259.1 +|-0.5 Ma"@en ; 
        
             rdfs:comment "younger bound -254.14 +|-0.07 Ma"@en ; 
        
             rdfs:label "Wuchiapingian Age"@en ; 
        
             owl:sameAs <http://dbpedia.org/resource/Wuchiapingian> ; 
        
             skos:broader isc:Lopingian ; 
        
             skos:broaderTransitive isc:Paleozoic ; 
        
             skos:broaderTransitive isc:Permian ; 
        
             skos:broaderTransitive isc:Phanerozoic ; 
        
             skos:inScheme ts:gts2018 ; 
        
             skos:notation "a1.1.3.1.1.2"^^gts:EraCode ; 
        
             skos:prefLabel "VuĿiapingis"@lt ; 
        
             skos:prefLabel "Wuchiaiping"@fi ; 
        
             skos:prefLabel "Wuchianpingum"@no ; 
        
             skos:prefLabel "Wuchiaping"@cs ; 
        
             skos:prefLabel "Wuchiaping"@pl ; 
        
             skos:prefLabel "Wuchiapingi"@et ; 
        
             skos:prefLabel "Wuchiapingian"@en ; 
        
             skos:prefLabel "Wuchiapingiano"@pt ; 
        
             skos:prefLabel "Wuchiapingien"@da ; 
        
             skos:prefLabel "Wuchiapingien"@fr ; 
        
             skos:prefLabel "Wuchiapingiense"@es ; 
        
             skos:prefLabel "Wuchiapingium"@de ; 
        
             skos:prefLabel "Wuchiapingiën"@nl ; 
        
             skos:prefLabel "wuchiaping"@sv ; 
        
             skos:prefLabel "wuchiapingi"@hu ; 
        
             skos:prefLabel "wuchiapingiano"@it ; 
        
             skos:prefLabel "wuchiapingij"@sl ; 
        
             skos:prefLabel "wuťiapching"@sk ; 
        
             skos:prefLabel "Вучиапинг"@bg ; 
        
             skos:prefLabel "ウキアピンギアン期"@ja ; 
        
             skos:prefLabel "吴家坪期"@zh ; 
        
             time:hasBeginning isc:BaseLopingian ; 
        
             time:hasEnd isc:BaseChanghsingian ; 
        
             time:intervalIn isc:Lopingian ; 
        
             time:intervalMeets isc:Changhsingian ; 
        
             time:intervalMetBy isc:Guadalupian ; 
        
             time:intervalStarts isc:Lopingian ; 
        
             foaf:primaryTopicOf <http://sweetontology.net/stateTimeGeologic/Wuchiapingian> ; 
        
           .

Is It not missing the information time:intervalMetBy isc:Capitanian?

The text was updated successfully, but these errors were encountered:

nicholascar · 2019-08-01T13:20:14Z

@dr-shorthair @smrgeoinfo this one's for you two.

dr-shorthair · 2019-08-14T01:45:08Z

A lot of relationships have not been included explicitly.

isc:Wuchiapingian
    time:intervalMetBy isc:Capitanian .

is implied by the inverse relationship

isc:Capitanian
      time:intervalMeets isc:Wuchiapingian .

which is present in the data. However, I have found a different error. Currently

isc:Guadalupian 
    time:intervalContains isc:Capitanian .

which should actually be

isc:Guadalupian 
   time:intervalEndedBy isc:Capitanian .

Overall there are a lot of relationships that are not included.
They could be added by running a whole lot of rules such as

'if A is met by B, and B is ended by C, then A is met by C'
'if D and E have the same end, and the beginning of E is after the beginning of D then E ends D' ... etc

These could be implemented as SPARQL CONSTRUCT or INSERT queries, but have not been designed yet. @hmuniz would you be interested in working through some of these?

arademaker · 2019-09-06T19:46:06Z

Hi @dr-shorthair , interesting suggestions. I can talk to my students to see how can we collaborate. We have recently wrote about an implementation of the same Ontology in SUMO.

Extending SUMO to Geological Times - Alexandre Tessarollo, Henrique Muniz, Alexandre Rademaker and Adam Pease

The question is if it makes sense to add explicitly the relations that could be inferred by the ontologies declarations. For instance, TIME ontology (https://www.w3.org/2006/time#) already has the definition:

:intervalMeets
  rdf:type owl:ObjectProperty ;
  rdfs:domain :ProperInterval ;
  rdfs:label "interval meets"@en ;
  rdfs:range :ProperInterval ;
  owl:inverseOf :intervalMetBy ;

arademaker · 2019-09-06T20:06:44Z

The declarations of the time:numericPosition in the gts:NumericEraBoundary as annotation properties makes no reasoning possible over these statements.

We don't have any explicit encoding of the approximation mark ~ in the chart (e.g. see BaseNorianTime).

arademaker · 2019-09-06T20:11:58Z

Dear @dr-shorthair, I wonder if we could separate the OWL files from the rest of the website files, that is, creating another repository for the ontologies. It would make easier the collaborative maintenance of the ontologies.

dr-shorthair · 2019-09-07T06:27:24Z

The declarations of the time:numericPosition in the gts:NumericEraBoundary as annotation properties

I don't understand why you are saying this. The time:numericPosition is defined in OWL-Time and is a Datatype Property.

We don't have any explicit encoding of the approximation mark ~ in the chart (e.g. see BaseNorianTime).

Correct. We did not attempt to encode "~".

creating another repository for the ontologies.

The ontologies are here: https://github.com/GeoscienceAustralia/geosciml.org/tree/master/resource/static/ontology/timescale

Yes, this is in the same repository as the instances https://github.com/GeoscienceAustralia/geosciml.org/tree/master/resource/static/vocabulary/timescale

But it is straightforward to fork the repository and then make pull requests back to the original. This repository is in the GeoscienceAustralia organization. The structure is rather complex, for historical reasons. However, I am not the organization or repo owner.

arademaker · 2019-09-07T12:59:48Z

Indeed, it is very strange how Protege is handling the properties. I am trying to understand why time:numericPosition is interpreted as annotation property but iso-trs:TM_OrdinalEra.begin as a data property, both declared in the same way. See the screenshot (the use of TM_OrdinalEra.begin was only for testing):

arademaker · 2019-09-07T13:18:41Z

But the most important thing is that if you change the value of time:numericPosition of the BaseAlbianTime to, let us say, 200, the reasoner will not sign any problem! This makes the model more vulnerable for inconsistencies.

Regarding the repository structure, IMHO it is not so straightforward to contribute for the ontologies in the given structure. First, in the practical side, the repository has 861MB, but ontologies alone have only 41MB

$ find . \( -name '*.rdf' -o -name '*.ttl' -o -name '*.owl' \) -exec du -ch {} +
...
388K	./resource/static/vocabulary/cgi/current/IUGS_CGI_register__for_INSPIRE_lithology_with_content.rdf
 20K	./resource/static/vocabulary/cgi/current/faultmovementsense.rdf
 41M	total

Second, as you said, the structure is not simple and we have to work in a complicated directory structure instead of having a more clear organization focus on the ontologies and their relations and versions. Moreover, I saw that you created a copy of the isc2018.ttl to isc2018-1.ttl instead of change the isc2018.ttl itself. The repository should work for versioning, but now we have versions and copies and a proliferation of files in the repository. Anyway, as I said, I believe if the ontologies are kept separated, it would make collaboration easier. But surely this is only a suggestion from someone interested in contribute. As far as I understood, this repository currently is the source of the website http://geosciml.org. right?

dr-shorthair · 2019-09-08T08:09:46Z

But the most important thing is that if you change the value of time:numericPosition of the BaseAlbianTime to, let us say, 200, the reasoner will not sign any problem! This makes the model more vulnerable for inconsistencies.

I don't understand what you are saying here.

Second, as you said, the structure is not simple and we have to work in a complicated directory structure instead of having a more clear organization focus on the ontologies and their relations and versions.

Indeed. The project has been underway for more than 10 years, and was originally hosted in a SVN repository. So some of the structure and versioning principles were just carried over from that. And also, until now, I was doing most of the editing and analysis alone so it didn't matter much. And it was convenient to leave it all in one repo since (as you surmised) that is used to build the geosciml.org website.

But if you guys are now truly interested in contributing then it probably would be helpful to do a refactor. We should probably maintain the ontology in a separate repo, and then just merge that into the build repo from time to time.

On the matter of the proliferation of versions in separate files - there are two motivations for this:

it was transported over from an earlier SVN repository
the dated versions primarily correspond to the dated versions published by the ICS. We actually think it is important to maintain these separate artefacts to reflect the governance artefacts.

But I agree that the 2018.ttl and 2018-1.ttl probably should be squashed now. I was treading carefully as the Geosciml people were a bit sensitive about some of the changes I was proposing. However, in the end I wound back the more radical changes, so it would be possible to squash it now, but I didn't get round to it yet. (This is not my day job...)

dr-shorthair · 2019-09-08T08:24:54Z

Note that the ontology was originally built on top of the ISO 19108 model, as implemented in https://github.com/ISO-TC211/GOM/tree/master/isotc211_GOM_harmonizedOntology/iso19108/2006 the structure of which is defined in ISO 19150-2.
This is the ontology that is described in our 2015 paper https://doi.org/10.1007/s12145-014-0170-6

However, I subsequently was involved in updating OWL-Time to accommodate the needs of non-Gregorian calendars, so it is now possible to use OWL-TIme instead of ISO 19108. So first I removed the dependencies on 19018 from https://github.com/GeoscienceAustralia/geosciml.org/blob/master/resource/static/ontology/timescale/thors.ttl and https://github.com/GeoscienceAustralia/geosciml.org/blob/master/resource/static/ontology/timescale/gts.ttl
Then I built W3C and ISO versions that import the neutral ontology and link it to either OWL-TIme or ISO 19108 here https://github.com/GeoscienceAustralia/geosciml.org/tree/master/resource/static/ontology/timescale/gts

It is all a bit of a tangled web, but like I said no-one else was much interested until now.

alexandretessarollo · 2019-12-01T04:45:29Z

I've been going through the isc2018-1.ttl, and found some inconsistencies:

line 580 says Asselian "time:intervalMetBy isc:UpperMississippian"
lines 5812 and 5813 say Capitanian "time:intervalDuring isc:Guadalupian" and "time:intervalIn isc:Guadalupian" - they are correct, but I believe we could change both for "time:intervalFinishes isc:Guadalupian"
line 11710 says Age Roadian is time:intervalMetBy isc:Capitanian, when Roadian actually takes place before Age Capitanian

I've a pull request addressing such points.

alexandretessarollo · 2019-12-01T04:54:06Z

But the most important thing is that if you change the value of time:numericPosition of the BaseAlbianTime to, let us say, 200, the reasoner will not sign any problem! This makes the model more vulnerable for inconsistencies.

I don't understand what you are saying here.

BaseAlbianTime has (line 782) "time:numericPosition 113.0", which is perfectly consistent with Albian being right after Aptian. But should one accidentally write, say, "time:numericPosition 1130", a reasoner would not sign any problem, despite Aptian ("time:numericPosition 125.0") being right before Albian.

smrgeoinfo · 2019-12-02T17:40:59Z

Off hand it seems that these kind of validation criteria could be set up with SWRL rules. It's not clear to me that they can be implemented with OWL constraints.
Something like: if (isc:x is time:intervalMetBy isc:y) then (isc:x/time:hasBeginning//time:numericPosition) > (isc:y/time:hasBeginning//time:numericPosition).

specific example:
if (isc:Roadian is time:intervalMetBy isc:Wordian) then (isc:Wordian/time:hasBeginning isc:BaseWordian//time:numericPosition) > (isc:Rodian/time:hasBeginning/isc:BaseRodian//time:numericPosition), as suggested above

I'll start a new issue on adding such validation rules. See #7

…- see GeoscienceAustralia/geosciml.org#3 (comment)

smrgeoinfo mentioned this issue Dec 2, 2019

add validation constraints on Geo Time scale ontology #7

Open

arademaker mentioned this issue Dec 13, 2019

Fork timescale components into a cleaner location(s) #8

Closed

dr-shorthair pushed a commit to dr-shorthair/timescale-data that referenced this issue Jan 13, 2020

Fix errors in Permian and Carboniferous, found by @alexandretessarollo …

9aa12b0

…- see GeoscienceAustralia/geosciml.org#3 (comment)

This was referenced Jan 17, 2020

possible extra validations CGI-IUGS/timescale-ont#1

Open

ISC ontology #4

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Wuchiapingian definition #3

Wuchiapingian definition #3

hmuniz commented Jul 18, 2019

nicholascar commented Aug 1, 2019

dr-shorthair commented Aug 14, 2019

arademaker commented Sep 6, 2019 •

edited

Loading

arademaker commented Sep 6, 2019

arademaker commented Sep 6, 2019

dr-shorthair commented Sep 7, 2019 •

edited

Loading

arademaker commented Sep 7, 2019

arademaker commented Sep 7, 2019

dr-shorthair commented Sep 8, 2019

dr-shorthair commented Sep 8, 2019

alexandretessarollo commented Dec 1, 2019

alexandretessarollo commented Dec 1, 2019

smrgeoinfo commented Dec 2, 2019 •

edited

Loading

Wuchiapingian definition #3

Wuchiapingian definition #3

Comments

hmuniz commented Jul 18, 2019

nicholascar commented Aug 1, 2019

dr-shorthair commented Aug 14, 2019

arademaker commented Sep 6, 2019 • edited Loading

arademaker commented Sep 6, 2019

arademaker commented Sep 6, 2019

dr-shorthair commented Sep 7, 2019 • edited Loading

arademaker commented Sep 7, 2019

arademaker commented Sep 7, 2019

dr-shorthair commented Sep 8, 2019

dr-shorthair commented Sep 8, 2019

alexandretessarollo commented Dec 1, 2019

alexandretessarollo commented Dec 1, 2019

smrgeoinfo commented Dec 2, 2019 • edited Loading

arademaker commented Sep 6, 2019 •

edited

Loading

dr-shorthair commented Sep 7, 2019 •

edited

Loading

smrgeoinfo commented Dec 2, 2019 •

edited

Loading