Skip to content

Creating and Editing Semantic Resources

Jump to bottom
Pierfrancesco Tommasino edited this page Feb 26, 2021 · 80 revisions

Creating and Editing Semantic Resource in VocBench

VocBench EcoPortal is an active service on the EcoPortal platform that allows you to edit and publish specific semantic resources in the ecological domain. To create a new project in VocBench EcoPortal you have two possibilities:

  1. If you are not registered you have to do it at the following link. After filling in some personal data, and if you already have a semantic resource published in EcoPortal, insert into “Existing semantic resource?” the full name and acronym, e.g., Fish Traits Thesaurus (FISHTRAITS). By default, the last version on EcoPortal is loaded, otherwise you have to specify the version from which to start editing in VocBench. NOTE: to request editing of an EcoPortal semantic resource, you must be the owner of that resource. Otherwise, in order to create a new semantic resource, you have to specify:

    • New semantic resource: the name of the project, e.g., Fish Traits Thesaurus. NOTE: it is suggested to specify the full name that will be used in EcoPortal;
    • BaseURI: the URL necessary for the creation of a project;
    • Model: the model of the new project which can be OWL or SKOS. NOTE: To understand the support of the SKOS model in EcoPortal we recommend reading the following section.

    Registration VocBench

  2. If you are already registered, click on the "Request Project" button in the Home Page and fill in the form as specified above.

    Request new Project

After this, the administrator will create a new project assigning you the role of Project Manager. The administrator will specify all technical details needed for the creation of the new project, e.g., lexicalisation, history, validation and blacklisting and the type of the repository access, whch is a remote triple store like GraphDB store.
Then in the list of projects, there should be a new item for the (empty) project. The open folder indicates that the project is open, but it may be necessary to click on the radio button on the left to access the project.

Open Project

Subsequent steps require moving to the “Data” tab to edit and then to export the data. In the “Scheme” tab, click on the create button to create a new skos:ConceptScheme ( []* ):

schema Tab

In the creation dialog, specify a label for the concept scheme being created e.g. “continents” in English and then click on the Ok button.

createconceptscheme

Then select the newly created scheme:

schema tab

In the Concept tab, click on the create button to create a new skos:Concept ( ()* ):

concept tab

In the creation dialog, specify a label for the concept being created e.g. “Africa” in English and then click on the Ok button.

create new concept

Do the same to create other concepts:

  • America
  • Asia
  • Europe
  • Oceania

At the end, the concept tree should contain a flat list of the five continents.

list concept

To understand in detail the different aspects of the user experience on VocBench, we recommend reading the following link.

EcoPortal Deployer for VocBench 3

  • Introduction

    The EcoPortal Deployer is a deployer for VocBench 3 allows the publication of semantic resources (specifically OWL ontologies or SKOS thesauri) on EcoPortal. The EcoPortal Deployer can be used in an export configuration whose target is a triple store: the EcoPortal Deployer directly consumes the RDF data being exported, without requiring that they be serialised beforehand into a byte sequence conforming to some format. Indeed, the serialisation occurs internally as part of the implementation of the submission protocol. The deployer provides a dedicated configuration for EcoPortal and its new mandatory metadata based on the Data Cite Metadata Schema. In addition, it is possible to configure the deployer also for generic OntoPortal catalogues (e.g., BioPortal).

  • How to use

    You, as project manager, can use the Deployer by selecting the Export Data item under the “Global Data Management” menu (in the top right corner of the user interface of VocBench 3).

    howtouse.png

    The “Export data” panel makes it possible to define complex export configurations. The panel consists of three sections:

    • Graphs to export: this section allows you to select which graphs will be exported. The default selection just contains the graph of your project, named with the base URI, which contains the data being edited.
    • Export transformations: this section allows for configuring a sequence of RDF Transformers, which can be used to manipulate the data being exported (e.g., filter out triples, add triples, replace triples, etc.)
    • Deployment: this section allows you to configure the destination of the data being exported and, optionally, transformed. You can choose from the dropdown menu whether the data will be saved to a file, exported to a triple store, or sent to a custom destination. As already discussed, the target of the EcoPortal Deployer is considered a triple store.

    globaldatamanagement.png

    After selecting “Deploy to a triple store” in the Deployment dropdown, the Deployer dropdown list will appear. Here you have to select “OntoPortal Deployer” and the item labelled EcoPortal to enable the specific characteristics of the deployer (e.g. additional configuration parameters) dedicated to EcoPortal, as depicted in the figure below.

    deployment.png

    Select the item labeled EcoPortal to enable the specific characteristics of the deployer (e.g. additional configuration parameters) dedicated to EcoPortal. The warning sign on the right of the widget associated with the OntoPortal Deployer indicates the necessity of further configuration. A click on the Configure button will open a dialog to edit the chosen configuration. Here below we summarise the configuration for EcoPortal, which consists of several fields:

    • API Base URL: the base URL of the OntoPortal REST API. If this parameter is omitted, then the deployer defaults to the official base URL of EcoPortal: http://ecoportal.lifewatchitaly.eu:8080/.
    • API key (mandatory): the API key that will be used to authorize the semantic resource submission. A user’s API key can be found in the user’s account page.
    • Acronym (mandatory): the acronym that identifies the semantic resource for which the submission is being made.
    • Description: a textual description of the semantic resource.
    • Version: the version of the semantic resource.
    • Format (mandatory): the format of the semantic resource (either OWL or SKOS).
    • Status (mandatory): the status of the semantic resource (either alpha, beta, production, retired).
    • Release Date (mandatory): the release date of the semantic resource, formatted as yyyy-mm-dd.
    • Contacts (mandatory): at least one contact for the semantic resource. Additional contacts can be added by clicking on the plus button on right. Each contact shall be formatted as name (email), such as Mario Bianchi (mario.bianchi@example.org).
    • Homepage: the address of the main web page of the semantic resource.
    • Documentation: the address of a web page providing documentation for the semantic resource.
    • Publications (mandatory): the address of a web page listing publications for the semantic resource.
    • Creators (mandatory): the main researchers involved in producing the data, or the authors of the publication, in priority order. It is required at least one creator.
    • Titles (mandatory): at least one name or title by which the resource is known.
    • Publisher (mandatory): the name of the entity that holds, archives, publishes prints, distributes, releases, issues, or produces the resource.
    • Publication year (mandatory): the year when the data was or will be made publicly available.
    • Resource type (mandatory): a description of the resource. The format is open, but the preferred format is a single term of some detail.
    • Resource type general(mandatory): the general type of resource.

    ecoportalmetadata.png

    The fields marked with an asterisk (*) are mandatory and all other fields are optional. Once the deployer has been configured, it is possible to click on the “Submit” button on the bottom of the “Export Data” panel to create the submission to EcoPortal. After a little while you should receive a confirmation message.

    export data success

  • Data transformation

    EcoPortal imposes some constraints for the semantic resources in SKOS format (see the documentation) and it requires (among other requirements):

    • The use of the property skos:hasTopConcept.

    • The use of plain (no- reified) SKOS labels.

      The first requirement is not met by VocBench by default (since it uses the inverse property skos:isTopConceptOf): however, an RDFTransformer can be used to add the triple expressing the relationship in the opposite direction. On the section “Export transformations”, click on the plus button and then select the “SPARQL RDF Transformer”.

      export transformation

      Click on the Configure button and specify the following filter in the configuration dialog (note that the “filter” field can be enlarged by dragging the grabber on the bottom right corner of the text area):

      INSERT {
      ?s <http://www.w3.org/2004/02/skos/core#hasTopConcept> ?c
      }WHERE {
      ?c <http://www.w3.org/2004/02/skos/core#topConceptOf> ?s
      }

      configurationSPRQLupdate.png

      The second requirement can be met by using SKOS as a lexicalization model. If a project uses SKOS-XL, it can be used as a dedicated RDFTrasformer to generate the plain labels from the reified ones.

  • Versioning

    Versioning is another item in the Global Data Management menu that allows you to save a snapshot of the data being edited.

    versioning.png

    Our suggestion is not to export the “CURRENT” version that denotes the continually evolving data being edited in a project. Indeed, any submission should be done through the following procedure:

    • create a dump of the data and assign it a version identifier;
    • temporarily switch to the dumped data;
    • make the submission using the already described export procedure: the field version in the configuration of the EcoPortal Deployer should match the version identifier of the data dump.

  • Verification

    Log in into EcoPortal and open the page of your target semantic resource.

    verification.png

    The semantic resource submission may not immediately appear on the EcoPortal web application in the list of the semantic resource submissions. Submissions are handled asynchronously: at first, we might see that the submission has just been Uploaded, but subsequently we should see that it is marked with Parsed, Indexed, Metrics and Annotator. In some circumstances, the new submission may not be visible at all just inside the web page. In this case, we can verify that EcoPortal has received the submission by retrieving the submissions using the REST API.

SKOS Support

  • Support for SKOS vocabularies in EcoPortal

    EcoPortal is a web-based portal for accessing and sharing semantic resources. The application accepts semantic resource submissions in OWL and OBO format, and SKOS vocabularies that contain particular constructs. This wiki page documents the minimum set of SKOS constructs that must be present in a SKOS vocabulary for EcoPortal to accept and handle the submission properly. Please note that the SKOS constructs described here are handled only for vocabularies that are identified as SKOS when they are submitted to EcoPortal.

    • 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, EcoPortal only treats the SKOS concept assertions as concepts to be displayed. If the vocabulary contains other assertions about other types of concepts, EcoPortal 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:

      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 & skos:hasTopConcept: For every semantic resource entry in EcoPortal, the application provides a tabbed interface with various views of the semantic resource data, e.g., a Classes tab with a tree structure to graphically depict the hierarchical collection of semantic resource classes.

      In the case of SKOS vocabularies, EcoPortal 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#> .
      @prefix ex: <http://www.example.com/> .

      ex:animalThesaurus rdf:type skos:ConceptScheme;
      skos:hasTopConcept ex:mammals;
      skos:hasTopConcept ex:fish.

      SKOS vocabularies submitted to EcoPortal 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:

      If your vocabulary declares more than one concept scheme, all of the top concepts will be aggregated and displayed as root level concepts. The EcoPortal user interface does not provide support for grouping top level concepts by concept scheme. It is highly recommended to declare an owl:Ontology, especially for metadata annotations.

    • Hierarchy in SKOS vocabularies

      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;
      skos:prefLabel "mammals"@en;
      skos:broader ex:animals.

      Other properties used to denote hierarchical relationships like skos:broaderTransitive, and skos:narrowerTranstive, are ignored.

    • Metrics data for SKOS vocabularies

      EcoPortal uses the OWL API for parsing all ontology and vocabulary submissions, as well as for the calculation of metrics data. The OWL API treats SKOS vocabularies as RDF files containing classes and instances. According to the SKOS Reference, concepts are instances of owl:Class, and thus are counted as instances (a.k.a. "individuals").

      When viewing metrics tables in the EcoPortal user interface, the value for the "NUMBER OF INDIVIDUALS" corresponds to the number of concepts in any given SKOS vocabulary.

      metrics_Fish_Traits_thesaurus in EcoPortal

    • SKOS-XL

      Currently EcoPortal offers no support for the SKOS eXtension for Labels (SKOS-XL). A suggested workaround for SKOS vocabularies that make use of SKOS-XL, is to dump the value of labels (i.e., skosxl:literalForm of skosxl:*Label instances) into the corresponding skos:*Label property.

  • 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 header shown here defines a few typical namespaces that may be useful.
      The last namespace is the one that defines this SKOS vocabulary. Ideally, the IRI defining the myskosid namespace is the resolvable location of the SKOS ontology.

      
   <xml version="1.0" encoding="UTF-8"?>
   <rdf:RDF
     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
     xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
     xmlns:skos="http://www.w3.org/2004/02/skos/core#"
     xmlns:dct="http://purl.org/dc/terms/"
     xmlns:myskosid="https://example.org/ontologies/myskosontology/"
   >

    • Example semantic resource description

      In the rdf:type item, this namespace is declared as the ConceptScheme. The ConceptScheme does not have to be the same as the namespace of the ontology.

      Other metadata is provided as an example of good practices in ontology metadata. The dct:creator does not have to be an ORCID ID, but a unique identifier is an ideal way of naming a creator (whether individual or organization).

      This semantic resource has only 2 concepts (to be defined below), hence only 2 skos:hasTopConcept declarations.

      
   <rdf:Description rdf:about="https://example.org/ontologies/myskosontology/">
     <rdfs:label xml:lang="en">Example SKOS ontology for EcoPortal</rdfs:label>
     <rdf:type rdf:resource="http://www.w3.org/2004/02/skos/core#ConceptScheme"/>
     <rdfs:comment xml:lang="en">Example created to simplify understanding and creation of a SKOS vocab for EcoPortal</rdfs:comment>
     <dct:created rdf:datatype="http://www.w3.org/2001/XMLSchema#date">2020-09-16</dct:created>
     <dct:modified rdf:datatype="http://www.w3.org/2001/XMLSchema#date">2020-09-16</dct:modified>
     <dct:license rdf:resource="https://creativecommons.org/licenses/by/4.0/"/>
     <dct:creator rdf:resource="https://orcid.org/0000-0001-6875-5360"/>
     <skos:hasTopConcept rdf:resource="https://example.org/ontologies/myskosontology/fragmentid001"/>
     <skos:hasTopConcept rdf:resource="https://example.org/ontologies/myskosontology/fragmentid002"/>
   </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 following.

      The rdf:Type and skos:prefLabel are required annotation content for EcoPortal to work effectively. Other items are optional.

      The skos:topConceptOf is not strictly required for EcoPortal SKOS semantic resources, 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 semantic resource.</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 semantic resource.</skos:definition>
     <skos:topConceptOf rdf:resource="https://example.org/ontologies/myskosontology/"/>
   </rdf:Description>

    • Closing XML

      Needed for a complete, parseable RDF file!

      </rdf:RDF>

Copyright © 2021, LifeWatch ERIC. All rights reserved.

EcoPortal

Clone this wiki locally