Ecoportal

_config.yml

@@ -229,5 +229,4 @@ defaults:
       portal: "EarthPortal"
       atom: "semantic artefact"
       atoms: "semantic artefacts"
-      display_ontoportal_icons: true
-      genericuribase: "https://w3id.org/earthsemantics"
+      display_ontoportal_icons: true

_includes/shared_doc/developer_guide/api_key.md

@@ -1,3 +1,7 @@
-Use of the {{ page.portal }} REST APIs requires an API key. The API key can be found in the Account Settings of logged in users.
+To use of the {{ page.portal }} REST APIs an API key is required. The API key can be found in the Account Settings of logged in users(see Figure 46).
 
-![How to retrieve your API key]({{site.figures_link}}/{{page.portal}}/find_apikey.png)
+![How to retrieve your API key]({{site.figures_link}}/{{page.portal}}/Figure46.png)
+{: .text-center }
+
+_Figure 46:   How to retrieve your API key._
+{: .text-center }

_includes/shared_doc/developer_guide/api_key_examples.md

@@ -1,9 +1,49 @@
-Use of the {{ page.portal }} REST APIs requires an API key. The API key can be found in the Account Settings of logged in users.
+An API Key is required to access any API call. It can be provided in three ways:
+- Using the API key query string parameter
+```
+#python code example
+import requests
+# example query string parameter on ontology media type:
+# 'https://data.ecoportal.lifewatch.eu/{media types}/{acronym}?apikey=your api key'
+res = requests.get('https://data.ecoportal.lifewatch.eu/ontologies/LUPO?apikey=7404e1c1-XXXX-XXXX-XXXX-XXXXXXXXXXX')
+Ontology_name = res.json()["name"]
+Ontology_id = res.json()["@id"]
+print(Ontology_name, Ontology_id)
+```
+```
+result : LifeWatch ERIC Upper Ontology https://data.ecoportal.lifewatch.eu/ontologies/LUPO
+```
 
-![How to retrieve your API key]({{site.figures_link}}/{{page.portal}}/find_apikey.png)
+- Providing an authorization header:
 
-1. Using the api key query string parameter: `'https://{{include.resturl}}/{media types}/{acronym}?apikey=your api key'`
+Authorization: apikey token=your_apikey
 
-2. Providing an Authorization header: `Authorization: apikey token=your_apikey` 
+```
+#python code example
+import urllib.request, urllib.error, urllib.parse
+import json
 
-3. When using a web browser to explore the API, if you provide your API Key once using method 1, it will be stored in a cookie for subsequent requests. You can override this by providing a different API Key in a new call.
+REST_URL = 'https://data.ecoportal.lifewatch.eu'
+API_KEY = "Your API Key"
+
+def get_json(url):
+opener = urllib.request.build_opener()
+opener.addheaders = [('Authorization', 'apikey token=' + API_KEY)]
+return json.loads(opener.open(url).read())
+
+
+# https://data.ecoportal.lifewatch.eu/{media types}/{acronym}
+resource = get_json(REST_URL + "/ontologies/LUPO")
+
+# get a desired resource attribute like name and id
+name = resource['name']
+id = resource['@id']
+
+print(name, id)
+```
+
+```
+result : LifeWatch ERIC Upper Ontology https://data.ecoportal.lifewatch.eu/ontologies/LUPO
+```
+
+- When using a web browser to explore the API, if you provide your API key once using method 1, it will be stored in a cookie for subsequent requests. You can override this by providing a different API key in a new call.

_includes/shared_doc/metadata_schema/MOD.md

@@ -1,5 +1,11 @@
+## {{ page.portal }} Metadata Schema
 The {{ page.portal }} Metadata Schema is built upon the Metadata Vocabulary for Ontology Description and Publication ([MOD 2.0](https://w3id.org/mod/2.0)). This comprehensive schema integrates various vocabularies, such as Dublin Core, OMV, DCAT, and VoID, and was introduced by [Dutta et al. 2017](http://dx.doi.org/10.1007/978-3-319-70863-8_17). Its primary purpose is to empower ontology developers to annotate and describe their ontologies, while also enabling ontology libraries to provide semantic descriptions of ontologies in the form of linked data.
 
-{{ page.portal }} with other members of the OntoPortal Alliance has embraced a set of 106 elements, comprising classes and properties organised into distinct categories. Each metadata element is linked to a FAIR principle, adding a layer of semantic richness to the description. The assessment of metadata elements is facilitated through the O'FAIRe tool, ensuring a systematic evaluation of the ontology's Findability, Accessibility, Interoperability, and Reusability aspects.
+{{ page.portal }} with other members of the OntoPortal Alliance has embraced a set of metadata elements, comprising classes and properties organised into distinct categories. Each metadata element is linked to a FAIR principle, adding a layer of semantic richness to the description. The assessment of metadata elements is facilitated through the O'FAIRe tool, ensuring a systematic evaluation of the ontology's Findability, Accessibility, Interoperability, and Reusability aspects.
+The table below lists all the metadata fields used in EcoPortal, and the FAIR sub-principles to which they are associated for the computation of the FAIR score.
 
-{{ page.portal }} administrators encourage the creators of semantic artefacts to compile the metadata fields by adding as much detail as possible to ensure the accurate communication of information to users and to be compliant to the FAIR principles when publishing a resource.
+__Note__: The column Cardinality indicates the quantity constraints for the metadata field. The possible values are:
+- 0-n = optional and repeatable;
+- 0-1 = optional, but not repeatable;
+- 1-n = mandatory and repeatable;
+- 1 = mandatory, but not repeatable.

_includes/shared_doc/ontology_lifecycle/feedback.md

@@ -1,3 +1,3 @@
-### Give feedback on {{ page.atoms }}
-{{ page.portal }} includes some community-oriented features such as: (ii) notes that can be attached in a forum-like mode to a specific artefact or class/concept, in order to discuss the ontology (its design, use, or evolution) or allow users to propose changes. (iii) change requests can be submitted, and in some cases directly transferred to external systems such as a GitHub issue tracker.
-Administrators encourage the users to engage in giving feedback on {{ page.atoms }} since each input is valuable in developing and publishing community-approved artefacts.
+## Give feedback on semantic artefacts
+{{ page.portal }} includes some community-oriented features in the [notes]({{ site.baseurl }}{% link docs/users-guide-docs/documentation/ecoportal/platform_overview/ontology_details.md %}) such as: (i) comments that can be attached in a forum-like mode to a specific artefact or class/concept, in order to discuss different specifications of the semantic artefact (its design, use, or evolution) or allow users to propose changes, and (ii) proposals that can be submitted within the portal.
+Administrators encourage the users to engage in giving feedback on semantic artefacts since each input is valuable in developing and publishing community-approved resources.

_includes/shared_doc/ontology_lifecycle/skos_support_1.md

@@ -1,4 +1,5 @@
-### SKOS Support
+## SKOS Support
 
-**Support for SKOS vocabularies in {{page.portal}}**
-{{ page.portal }} serves as a web-based portal designed for the access and exchange of {{include.atoms}}. The platform is capable of receiving {{include.atom}} submissions in OWL and OBO formats, as well as SKOS vocabularies containing specific constructs. This guide outlines the essential set of SKOS constructs required in a vocabulary for proper acceptance and handling within {{ page.portal }}. It is important to emphasise that the described SKOS constructs are specifically processed for vocabularies identified as SKOS during their submission to {{ page.portal }}.
+### Support for SKOS vocabularies in {{page.portal}}
+
+{{ page.portal }} serves as a web-based portal designed for the access and exchange of semantic artefacts. The platform is capable of receiving semantic artefact submissions in OWL and OBO formats, as well as SKOS vocabularies containing specific constructs. This guide outlines the essential set of SKOS constructs required in a vocabulary for proper acceptance and handling within EcoPortal. It is important to emphasise that the described SKOS constructs are specifically processed for vocabularies identified as SKOS during their submission to {{ page.portal }}.

_includes/shared_doc/ontology_lifecycle/skos_support_2.md

@@ -1,12 +1,15 @@
-**Required SKOS constructs**
-skos:Concept. Concepts are the fundamental elements of SKOS vocabularies and are asserted using the skos:Concept class, e.g.: <http://www.example.com/animals> rdf:type skos:Concept
-In SKOS vocabularies, {{ page.portal }} only treats the SKOS concept assertions as concepts to be displayed. If the vocabulary contains other assertions about other types of concepts, {{ page.portal }} will not treat these as concepts in any of its displays or features. See the W3C's SKOS System Primer and SKOS Reference for concept documentation and examples.
+### Required SKOS constructs
 
-Note: Some OWL ontologies declare the SKOS namespace to facilitate minimal use of SKOS constructs for things like labels (e.g., skos:prefLabel, skos:altLabel) or mappings (e.g., skos:exactMatch, skos:broaderMatch). In these cases, the proper format for new ontology submissions is OWL, not SKOS.
-skos:ConceptScheme and skos:hasTopConcept. For every {{ page.atom }} entry in {{ page.portal }}, the application provides a tabbed interface with various views of the {{ page.atom }} data, e.g., a "Classes" tab with a tree structure to graphically depict the hierarchical collection of {{ page.atom }} classes.
+- **skos:Concept**. Concepts are the fundamental elements of SKOS vocabularies and are asserted using the skos:Concept class, e.g.: <http://www.example.com/animals> rdf:type skos:Concept
+  In SKOS vocabularies, {{ page.portal }} only treats the SKOS concept assertions as concepts to be displayed. If the vocabulary contains other assertions about other types of concepts, {{ page.portal }} will not treat these as concepts in any of its displays or features. See the W3C's [SKOS System Primer](https://www.w3.org/TR/2009/NOTE-skos-primer-20090818/#secconcept) and [SKOS Reference](https://www.w3.org/TR/2009/NOTE-skos-primer-20090818/#secconcept) for concept documentation and examples.
+
+**Note**: Some OWL ontologies declare the SKOS namespace to facilitate minimal use of SKOS constructs for things like labels (e.g., skos:prefLabel, skos:altLabel) or mappings (e.g., skos:exactMatch, skos:broaderMatch). In these cases, the proper format for new ontology submissions is OWL, not SKOS.
+
+- **skos:ConceptScheme** and **skos:hasTopConcept**. For every semantic artefact entry in EcoPortal, the application provides a tabbed interface with various views of the semantic artefact data, e.g., a "Classes" tab with a tree structure to graphically depict the hierarchical collection of semantic artefact classes.
 In the case of SKOS vocabularies, {{ page.portal }} determines which concepts to display as roots in the concept tree by querying vocabulary content for occurrences of skos:hasTopConcept property assertions. Top concepts are the most general concepts contained in SKOS concept schemes (an aggregation of one or more SKOS concepts).
 The following example, taken from the SKOS System Primer, shows how to define a concept scheme and link it to the most general concepts it contains:
 
+
 ```
 @prefix skos: <http://www.w3.org/2004/02/skos/core#> 
 @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> 
@@ -17,5 +20,6 @@ skos:hasTopConcept ex:mammals
 skos:hasTopConcept ex:fish
 ```
 
-SKOS vocabularies submitted to {{ page.portal }} must contain a minimum of one concept scheme and top concept assertion. See the SKOS System Primer and SKOS Reference for more documentation of concept schemes and top concepts.
+SKOS vocabularies submitted to {{ page.portal }} must contain a minimum of one concept scheme and top concept assertion. See the [SKOS System Primer](https://www.w3.org/TR/2009/NOTE-skos-primer-20090818/#secscheme) and [SKOS Reference](https://www.w3.org/TR/2009/NOTE-skos-primer-20090818/#secscheme) for more documentation of concept schemes and top concepts.
 If your vocabulary declares more than one concept scheme, all of the top concepts will be aggregated and displayed as root level concepts. The {{ page.portal }} user interface offers functionality to group these top-level concepts based on their respective concept schemes, accessible through the implemented filters.
+

_includes/shared_doc/ontology_lifecycle/skos_support_3.md

@@ -1,6 +1,6 @@
-**Hierarchy in SKOS vocabularies**
+### Hierarchy in SKOS vocabularies
 
-The only semantic relationship in SKOS vocabularies that {{page.portal}} uses to construct and display concept hierarchies is the skos:broader property.
+The only semantic relationship in SKOS vocabularies that EcoPortal uses to construct and display concept hierarchies is the skos:broader property.
 
 ```
 ex:mammals rdf:type skos:Concept;

_includes/shared_doc/ontology_lifecycle/skos_support_4.md

@@ -1,3 +1,4 @@
-**Metrics data for SKOS vocabularies**
-{{ page.portal }} employs the OWL API to parse all ontology and vocabulary submissions, including the computation of metric data. The OWL API interprets SKOS vocabularies as RDF files that encompass classes and instances. Following the SKOS Reference, concepts are identified as instances of owl:Class, consequently, they are counted as instances, also referred to as "individuals."
-When examining metric tables within the {{ page.portal }} user interface, the "Number Of Individuals" value aligns with the count of concepts within a given SKOS vocabulary.
+### Metrics data for SKOS vocabularies
+
+{{ page.portal }} employs the [OWL API](https://owlcs.github.io/owlapi/) to parse all ontology and vocabulary submissions, including the computation of metric data. The OWL API interprets SKOS vocabularies as RDF files that encompass classes and instances. Following the SKOS Reference, concepts are identified as instances of owl:Class, consequently, they are counted as instances, also referred to as "individuals".
+When examining [metric tables]({{ site.baseurl }}{% link docs/users-guide-docs/documentation/ecoportal/platform_overview/ontology_details.md %}) within the {{ page.portal }} user interface, the "Number Of Individuals" value aligns with the count of concepts within a given SKOS vocabulary.

_includes/shared_doc/ontology_lifecycle/skos_support_5.md

@@ -1,7 +1,8 @@
-**Example of valid SKOS**
+### Example of valid SKOS
+
 This example provides a simple illustration of the composition of a SKOS file that complies with the above constraints.
-- **Example header**. The provided header establishes several common namespaces that could prove valuable. The final namespace is the one responsible for defining the specific SKOS vocabulary in question. Ideally, the IRI associated with the "myskosid" namespace should be a resolvable location pointing to the SKOS ontology.
-    ```
+- **Example header**. The provided header establishes several common namespaces that could prove valuable. The final namespace is the one responsible for defining the specific SKOS vocabulary in question. Ideally, the IRI associated with the "myskosid" namespace should be a resolvable location pointing to the SKOS semantic artefact.
+  ```
    <xml version="1.0" encoding="UTF-8"?>
    <rdf:RDF
      xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
@@ -10,7 +11,7 @@ This example provides a simple illustration of the composition of a SKOS file th
      xmlns:dct="http://purl.org/dc/terms/"
      xmlns:myskosid="https://example.org/ontologies/myskosontology/" >
     ```
-- **Example {{ page.atom }} description**. In the rdf:type item, this namespace is declared as the ConceptScheme. It's important to note that the ConceptScheme doesn't necessarily have to match the ontology's namespace. Additional metadata examples are given as good practices in ontology metadata. While dct:creator doesn't necessarily need to be an ORCID ID, having a unique identifier is recommended for identifying the creator, whether an individual or organisation. This {{ page.atom }} comprises only two concepts (to be defined later), resulting in only two skos:hasTopConcept declarations.
+- **Example {{ page.atom }} description**. In the rdf:type item, this namespace is declared as the ConceptScheme. It is important to note that the ConceptScheme doesn't necessarily have to match the semantic artefact namespace. Additional metadata examples are given as good practices in semantic artefact metadata curation. While dct:creator doesn't necessarily need to be an ORCID ID, having a unique identifier is recommended for identifying the creator, whether an individual or organisation. This semantic artefact comprises only two concepts (to be defined later), resulting in only two skos:hasTopConcept declarations.
     ```
     <rdf:Description rdf:about="https://example.org/ontologies/myskosontology/">
     <rdfs:label xml:lang="en">Example SKOS ontology for {{ page.portal }}</rdfs:label>
@@ -25,18 +26,18 @@ This example provides a simple illustration of the composition of a SKOS file th
     </rdf:Description>
     ```
 
-- **Example term definitions**. This section shows the two concepts and a few typical annotations about those concepts. The first rdf:Description line of each group names the concept that is being defined in the indented lines that follows. The rdf:Type and skos:prefLabel are required annotation content for {{ page.portal }} to work effectively. Other items are optional. The skos:topConceptOf is not strictly required for {{ page.portal }} SKOS {{ page.atoms }}, but provides useful contextualization if there is more than one topConcept.
+- **Example term definitions**. This section shows the two concepts and a few typical annotations about those concepts. The first rdf:Description line of each group names the concept that is being defined in the indented lines that follows. The rdf:Type and skos:prefLabel are required annotation content for {{ page.portal }} to work effectively. Other items are optional. The skos:topConceptOf is not strictly required for {{ page.portal }} SKOS semantic artefacts, but provides useful contextualization if there is more than one topConcept.
     ```
     <rdf:Description rdf:about="https://example.org/ontologies/myskosontology/fragmentid001"">
     <rdf:type rdf:resource="http://www.w3.org/2004/02/skos/core#Concept"/>
     <skos:prefLabel xml:lang="en">First concept</skos:prefLabel>
-    <skos:definition xml:lang="en">The very first example provided as part of this {{ page.atom }}.</skos:definition>
+    <skos:definition xml:lang="en">The very first example provided as part of this semantic artefact.</skos:definition>
     <skos:topConceptOf rdf:resource="https://example.org/ontologies/myskosontology/"/>
     </rdf:Description>
     <rdf:Description rdf:about="https://example.org/ontologies/myskosontology/fragmentid002"">
     <rdf:type rdf:resource="http://www.w3.org/2004/02/skos/core#Concept"/>
     <skos:prefLabel xml:lang="en">Second concept</skos:prefLabel>
-    <skos:definition xml:lang="en">The very first example provided as part of this {{ page.atom }}.</skos:definition>
+    <skos:definition xml:lang="en">The very first example provided as part of this semantic artefact.</skos:definition>
     <skos:topConceptOf rdf:resource="https://example.org/ontologies/myskosontology/"/>
     </rdf:Description>
     ```