{"id":2994,"date":"2017-06-23T20:16:49","date_gmt":"2017-06-23T20:16:49","guid":{"rendered":"https:\/\/notebooks.dataone.org\/?p=2994"},"modified":"2017-06-23T20:17:35","modified_gmt":"2017-06-23T20:17:35","slug":"week-4-ecso-knowledge-representation-and-carbon-cycling-incorporation","status":"publish","type":"post","link":"https:\/\/notebooks.dataone.org\/controlled-vocab\/week-4-ecso-knowledge-representation-and-carbon-cycling-incorporation\/","title":{"rendered":"Week 4: ECSO knowledge representation and carbon cycling incorporation"},"content":{"rendered":"

This week we had two goals 1) to further define our knowledge representation structure by going through the ECSO ontology and determining which custom annotations can be systematically replaced with standard SKOS elements and 2) to improve the thematic contents of interest within the ontology related to carbon cycling.<\/p>\n

For the first task I systematically went through the classes to establish the \u2018design pattern\u2019 for the ontology. For example, does each term have a rdfs:label, or skos:prefLabel, or both ? There were only a couple of skos labels used in the ontology and rdfs:labels were abundant. As I mentioned last week there were 52 terms for which the rdfs:label was absent. So, using the IRI link to the ontology label I added the rdfs:label to those 52 terms. While these terms lack all other annotation information the others within the onotology vary \u00a0in their notation. For example the class \u2018concentration of\u2019 has annotations of: rdfs:label, id, definition, hasOBONamespace, hasDbXref, definition_Source, has_Exact_Synonym, and inSubset; however, the class \u2018Count\u2019 has an rdfs:label, definition, definition_Contributor, definition_Source, has_Related_Synonym. While the two both have rdfs:label, definition, and definition_Source the differences between the two classes is primarily due to their origin. While \u2018concentration of\u2019 is imported from PATO <\/a>(Phenotypic Quality Ontology)\u00a0the class \u2018Count\u2019 is a custom ECSO term, as a result of this, PATO is on the Obofoundary website<\/a> and has a OBO namespace while ECSO does not and so the term does not contain this annotation information. Within ECSO the term \u2018Count\u2019 is defined as \u2018the total number counted\u2019 while, PATO has a term \u2018amount\u2019 which has_Exact_Synonym:count it is defined as \u2018the number of entities of this type that are part of the whole organism\u2019 and does not function for DataONE\u2019s semantic needs. The proceeding example demonstrates how I evaluated each term. In the previous case \u2018count\u2019 had no id in the annotation field and this is true for all the native ECSO terms. The addition of ECSO ids to each class is an example of one of the ways we can improve knowledge representation within ECSO. Following the analysis of the current state of the ECSO knowledge representation I have determined that the following elements should be present in all class annotations rdfs:label, id, definition, definition_Source, and definition_Contributor or created_by (if native). All other information is conditional dependent on the source that the term is imported from and the information therein (ex. has_DbXref or has_OBONamespace). I have begun to edit each term to insure they contain all pertinent information within their annotation section.<\/p>\n

The second task this week, to improve the thematic content of ECSO with regards to carbon cycling, is less straightforward. The existing class structure within ECSO contains several carbon cycling related terms. Key among these terms are \u2018carbon pool\u2019 and \u2018carbon cycling\u2019 shown in the figures below as they are currently structured into the ECSO framework.<\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

As you can see, the term \u2018carbon cycling\u2019 is a subclass of \u2018Environmental System Process\u2019, which is a subclass of \u2018Process\u2019 a subclass of \u2018Occurrent.\u2019 The class \u2018Occurrent\u2019 is a sibling class of the class \u2018Entity\u2019 of which \u2018Carbon Pool\u2019 is a subclass. As you can see there is a fair bit of preexisting structure with which I can begin building the carbon cycling ontology into ECSO. Now in conceptualizing the carbon-cycle the first thing that comes to mind is the classic illustration diagrams that I am sure you are familiar with, such as the one below from NASA shown below.<\/p>\n

<\/p>\n

In the illustration we see that each \u2018Entity\u2019 \u2013 \u2018Carbon Pool\u2019 of the carbon cycle is labeled and has a \u2018Occurrent\u2019 -\u2018Process\u2019 associated with it depicted by the arrows indicating carbon exchange between each \u2018Entity.\u2019 In the ECSO framework however \u2018Process\u2019 is currently classified as both an \u2018Occurrent\u2019 and an \u2018Entity.\u2019 This dual classification may seem confusing but this depends on how we define the terms \u2018Entity\u2019 and \u2018Occurrent.\u2019 In fact within ECSO \u2018Occurrent\u2019 is defined as \u201can entity that has temporal part and that happens, unfolds or develops through time.\u201d And so it makes sense that the \u2018Process\u2019 is both an \u2018Entity\u2019 and an \u2018Occurrent.\u2019<\/p>\n

Currently, ECSO is missing these arrows within the ontology. Next week, I plan to add these connections via the Object Properties \u2018hasProcess\u2019 and the inverse \u2018hasComponent\u2019. For example the \u2018Atmospheric Carbon Dioxide Pool\u2019 hasComponent \u2018carbon dioxide\u2019 and the class \u2018Leaf Litter Carbon Pool\u2019 hasProcess \u2018decomposition.\u2019 In addition to this I will be organizing the many terms I have identified as being essential for DataONE semantics concerning carbon-cycling into ECSO.<\/p>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

This week we had two goals 1) to further define our knowledge representation structure by going through the ECSO ontology and determining which custom annotations can be systematically replaced with standard SKOS elements and 2) to improve the thematic contents of interest within the ontology related to carbon cycling. For Continue reading Week 4: ECSO knowledge representation and carbon cycling incorporation<\/span>→<\/span><\/a><\/p>\n","protected":false},"author":106,"featured_media":2995,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[376],"tags":[],"_links":{"self":[{"href":"https:\/\/notebooks.dataone.org\/wp-json\/wp\/v2\/posts\/2994"}],"collection":[{"href":"https:\/\/notebooks.dataone.org\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/notebooks.dataone.org\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/notebooks.dataone.org\/wp-json\/wp\/v2\/users\/106"}],"replies":[{"embeddable":true,"href":"https:\/\/notebooks.dataone.org\/wp-json\/wp\/v2\/comments?post=2994"}],"version-history":[{"count":2,"href":"https:\/\/notebooks.dataone.org\/wp-json\/wp\/v2\/posts\/2994\/revisions"}],"predecessor-version":[{"id":2998,"href":"https:\/\/notebooks.dataone.org\/wp-json\/wp\/v2\/posts\/2994\/revisions\/2998"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/notebooks.dataone.org\/wp-json\/wp\/v2\/media\/2995"}],"wp:attachment":[{"href":"https:\/\/notebooks.dataone.org\/wp-json\/wp\/v2\/media?parent=2994"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/notebooks.dataone.org\/wp-json\/wp\/v2\/categories?post=2994"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/notebooks.dataone.org\/wp-json\/wp\/v2\/tags?post=2994"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}