# Building a consistent Information System in the different nodes and defining standardisation strategies

Romain David, Jean-Eudes Hollebecq, Pascal Neveu

► To cite this version:

Romain David, Jean-Eudes Hollebecq, Pascal Neveu. Building a consistent Information System in the different nodes and defining standardisation strategies. 2. Annual Meeting EPPN2020, Wageningen University and Research Centre (WUR). NLD., May 2019, Wageningen, Netherlands. 32 p. hal-02787524

HAL Id: hal-02787524

https://hal.inrae.fr/hal-02787524

Submitted on 5 Jun 2020

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
2nd Annual Meeting May 2019

WUR - NL

Romain David - Jean-Eudes Hollebecq -
Pascal Neveu, INRA
<figure><img src="image_2.png" /></figure>

JRA3

‘Building a consistent Information
System in the different nodes and
defining standardisation strategies’
<figure><img src="image_3.png" /></figure>

* **Object identification**
  Objects: plants, plots, experiments, sensors, events, etc
  Identification: persistent, unambiguous, resolvable

* **Variable naming and formalization**
  Give (local or global) name to variables
  What (concept), How, Associated controlled contexts

* **Data interoperability**
  Formats, schemas, semantic
  Representation compatibility and consistency
<figure><img src="image_4.png" /></figure>

# Object Identification

## What do we want to identify?

### Organisational objects and actors:

Organisations, Experiments, Locations, Operators, Softwares, etc.

<figure><img src="image_5.png" /></figure>

### Biological material:

Plants, Leaves, Stems, Flowers, Roots, etc.

### Omics data:

Proteins, Spectrum, Transcriptum, etc.

### Experimental Material:

Sensors, Pots, Substrats, etc.

<figure><img src="image_6.png" /></figure>
# Object Identification

What do we want to identify?

**Collaborative objects, resources:**

Aggregated data, Concepts, Sample-analysis, etc

**Events and activities**

Faults, Management, Disturbance, Meteo, etc.

**Digital resources :**

Datasets, Reports, Papers, etc.

<figure><img src="image_7.png" /></figure>

<figure><img src="image_8.png" /></figure>
# Object Identification

**Concepts / Classes:** Pot, Plant, Leaf

**Instances:** pot22, pot17, leaf234, plant12

<figure><img src="image_9.png" /></figure>
# Object Identification

## What is an identifier?

An identifier is a sort of name (could be alphanumeric or numeric only) that identifies a specific object (digital or not) in a set of objects.

DOI or URI are string that identifies a particular resources

DOI: 10.1111/nph.15385 → http://doi.org/10.1111/nph.15385

http://www.inra.fr/mp3/2015/arch/exp21/plant227

<figure><img src="image_10.png" /></figure>

In an ideal world identifier should be **unique for each object (bijection)**, **In practice this is rarely the case.**
# Object Identification

How do we want to identify? good **identifier**.

**Non ambiguous**

An identifier only stands for one resource. Whatever the database or source, two objects can not have the same identifier.

ID36B2

<figure><img src="image_11.png" /></figure>

<figure><img src="image_12.png" /></figure>

<figure><img src="image_13.png" /></figure>

**Confusions happens** when different resources share the same identifier.

ID36B2

<figure><img src="image_14.png" /></figure>

<figure><img src="image_15.png" /></figure>

<figure><img src="image_16.png" /></figure>

This characteristic is **mandatory** for identifiers.
# Object Identification

How do we want to identify? **good _identifier_**.

**Non ambiguous**

An identifier only stands for one resource. Whatever the database or source, two objects can not have the same identifier.

**Confusions happens** when different resources share the same identifier.

This characteristic **is mandatory** for identifiers.

<figure><img src="image_17.png" /></figure>

<figure><img src="image_18.png" /></figure>

can change over time:
e.g. **plot cutting**
# Object Identification

How do we want to identify? good **identifier**.

## Non ambiguous Persistent

A persistent identifier is an identifier that is **permanently assigned to an object**
(Ideally usable in <u>several decades</u>).

Aims : reusability of data over the long term (H2020 requirement)

The problem is that during periods of decades, many changes can occur within
databases, but also in institutions or organizations in charge of the data.
It is thus necessary to preserve and recover dependencies between these
elements, this in time and localisation.
How do we want to identify? With an **efficient identifier**.

**Non ambiguous**
**Persistent**
**Resolvable (Dereferencable)**

<figure><img src="image_19.png" /></figure>

An identifier is said to be dereferenceable if it is possible to access the object or all the digital contents describing the object (e.g. URL, URI...).
What do **we want to avoid** for an efficient identification?

**Non usability for operators:**

* No semantic in the identifier / excessively long

* 10908538265365831680853826536583168

* http://www.domainname.fr/m3p/arch2017c17000915/FMfcgxwCgCSgPwdZxzkZtSHhnmvWWcpp

<figure><img src="image_20.png" /></figure>

* Confusing letters

* Little L and maj i : I & I are not easily differentiable

* (idem for O letter and 0 number)

* Too much semantic in the identifier (avoid optional metadata)

* (http://www.domainname.fr/m3p/Program/work_package/Country/Site/Year/Month/Day/Operator/Plant/Leave/Method/Color_of_the_pen/Length)
<figure><img src="image_21.png" /></figure>

Country1/CityC/FieldF/TreatmentT/MaizeA

<figure><img src="image_22.png" /></figure>

Semantic

<figure><img src="image_23.png" /></figure>

<figure><img src="image_24.png" /></figure>

common
sense

<figure><img src="image_25.png" /></figure>

Trade of

<figure><img src="image_26.png" /></figure>

<figure><img src="image_27.png" /></figure>

<figure><img src="image_28.png" /></figure>

Opaque

2sv67sMP
# Identification

## Summary of what we want for an efficient identification

* **Non ambiguous**

* **Persistent (based on data authority)**

* **Potentially resolvable (Dereferencable / web compatible)**

And

* **Only one language** (english, other languages can be generated by alias)

* **Minimum recognizable semantic part**
  (Human readable to know unambiguously what it is during manipulations)

* **Not too long**

* **Easy to generate and use**

**Data authority:** a community approved and identified institution or body that is responsible of any type of action concerning data on the long term.

<figure><img src="image_29.png" /></figure>

Agility needed for
the long term
maintenance!!
# Variable naming

## Variable naming and variable representation

* Measuments / observations / aggregated / calculated

**potentially associated to all object types:** biological material, events, organizational objects

## And be

* unidimensional or multidimensional

* quantitative, qualitative, symbolic (intervals)

* spatial, temporal, thermal time

* phenotypic, environmental
<figure><img src="image_30.png" /></figure>

# Naming rules

## How to define a variable?

The example of *Plant Height*

- Plant with root?

- Plant with flower?

- Stem and leaves?

- Only the stem?

- Dry or not?

- In the morning or the end of the day?

<figure><img src="image_31.png" /><figcaption>Figure From D. Pot, CIRAD</figcaption></figure>

Plant Height
# Variable naming

## What do we want to avoid in global context

* several names for same variable

* same name for several variable →

* Sharing fuzzy or unstable variables

* Zero semantic name

* Beware I (i) I (L) O and O (zero) in names

* No optional metadata in names

<figure><img src="image_32.png" /><figcaption>Figure From D. Pot, CIRAD</figcaption></figure>
<figure><img src="image_33.png" /></figure>

Variable naming

What do we recommended in global context

- Unambiguous name (in global context)

- Accessible description of variable
  Description can be read by machine and human

- Try to reuse existing variable if available

- Use standardized/shared representation schema for formalisation
  of new variable (and share it)
# Variable naming

Variable representation schema for phenotypic variable

Variable = Trait + Method + Unit

Trait = Entity + Attribute (or Quality)

Entity, Attribute, Method and Unit must be referenced (if possible)
in references ontologies and semantic resources:

Crop O., Trait O., Plant O., PATO, Agrovoc, ENVO, etc
## x² Variable Description

<figure><img src="image_34.png" /></figure>

Add annotation

<figure><img src="image_35.png" /></figure>

Add event

Return to the list

<figure><img src="image_36.png" /></figure>

### Variable

<table><tr><td>Internal Name</td><td>GroundCover_GrndCov_percentage</td></tr><tr><td>URI</td><td>http://www.phenome-fppn.fr/m3p/variable/v000006</td></tr><tr><td>Related References</td><td>skos:closeMatch CO_321:0001104</td></tr><tr><td>Definition</td><td>Crop ground cover, or the percentage of soil surface covered by plant foliage.</td></tr></table>

View RDF

### Trait

<table><tr><td>Internal Name</td><td>GroundCover</td></tr><tr><td>URI</td><td>http://www.phenome-fppn.fr/m3p/variable/t000006</td></tr><tr><td>Related References</td><td>skos:exactMatch CO_321:0000014</td></tr></table>

### Method

<table><tr><td>Internal Name</td><td>GrndCov</td></tr><tr><td>URI</td><td>http://www.phenome-fppn.fr/m3p/variable/m000006</td></tr><tr><td>Related References</td><td>skos:exactMatch CO_321:00000405</td></tr></table>

### Unit

<table><tr><td>Internal Name</td><td>percentage</td></tr><tr><td>URI</td><td>http://www.phenome-fppn.fr/m3p/variable/u000006</td></tr><tr><td>Related References</td><td>(not set)</td></tr></table>
# Naming rules - concepts

<figure><img src="image_37.png" /></figure>
<figure><img src="image_38.png" /></figure>

# Naming rules

<figure><img src="image_39.png" /></figure>
# Naming rules

## What do we want to control in the name (or in alias)?

*Importance of a controlled context*

<figure><img src="image_40.png" /></figure>

Example of an UAV for remote sensing in the field

**Controlled context data**

- X, Y, Z, time, speed

- Sensor type (RGB, NDVI, etc.)

- Wind mean measurement

**Not controlled context:** Cloud, variability of wind

**Not controlled context** affect the measure
(example of the clouds for the light)
# Interoperability

**Interoperable Informations systems** allow data exchange and reuse among scientific disciplines, organisations and countries through **syntactically parseable and semantically understandable operations.**

<figure><img src="image_41.png" /></figure>
## Improvement needs:

- Data format

- Data typology

- Shared semantics

- Rate of database updates

- Architecture

- Data qualification

- Taxonomic framework

- Repository of actors

- Conditions of use

- Accessibility

- Geographical repository

- ...

## Interoperability ?

*Compatibility*

<figure><img src="image_42.png" /></figure>

*Standard*

<figure><img src="image_43.png" /></figure>

*Interoperability*

<figure><img src="image_44.png" /></figure>
# Interoperability

Bad practices ?

<figure><img src="image_45.png" /></figure>

?

<figure><img src="image_46.png" /></figure>

<figure><img src="image_47.png" /></figure>

A & B are compatibles *in another way* than C & D :

Harder now to interoperate
A & B with C & D

Interoperability is *not only* with your domain:

**Do not create your own format / ontology**
without prospecting communities approved
standards (in & *outside of your community*)
Improvement locks:
**Too much standards and**
**speed of**
**standard evolution**

Data format, Data typology, semantics & ontologies, Data qualification, Data standards... tools, technologies, groups...

OGC®
Open Geospatial Consortium, Inc.

W3C®

<figure><img src="image_48.png" /></figure>

International
Organization for
Standardization

<figure><img src="image_49.png" /></figure>

Source: Julian Bardo IRD

<figure><img src="image_50.png" /></figure>

Data cost

<figure><img src="image_51.png" /></figure>

Skills
availability
# Interoperability

## Interoperating in a safe way:

**Working on interoperability also needs to work on traceability**

**Provenance → Data traceability** is the capability to trace data and **each stage of their transformation**.

<figure><img src="image_52.png" /></figure>

**Challenge :**

- Identifying

- 100% objects,

- 100% actors,

- 100% transformations

<figure><img src="image_53.png" /></figure>

<figure><img src="image_54.png" /></figure>
# Interoperability

## Provenance (data traceability) challenge

Provenance is the capability to trace data and **each of their transformation**.

* ability to verify the

* History / origin

* location

* curation

* keep track of a given set of
information

* in several distant information
systems

* within time

* keep track of the different versions

* by means of

* Well documented

* Metadata availability

* Unambiguous
identification

* Naming
# Interoperability

## Interoperating in an efficient way:

**Working on quality level of interoperability**

<figure><img src="image_55.png" /></figure>

**Need to be maintained on the long term!**

**take into account the persistence of human resources and skills**

Romain David, Laurence Mabile, Mohamed Yahia, Anne Cambon-Thomsen, Anne-Sophie Archambeau, et al.. How to assess FAIRness to improve crediting and rewarding processes for data sharing? A step forward towards an extensive assessment grid. RDA 13th (P13) Plenary Meeting, Apr 2019, Philadelphia, United States. <https://www.rd-alliance.org/rda-13th-plenary-meeting-information>. <https://zenodo.org/12625721>. <https://wwwFFE-02094678>
ARK:https://tools.ietf.org/html/draft-kunze-ark-18B2HANDLE: https://github.com/EUDAT-B2SAFE/B2HANDLE CROP Ontology:

https://github.com/bioversity/Crop-OntologyDOI: https://www.doi.org/ePIC: https://www.pidconsortium.eu/GUID:

https://fr.wikipedia.org/wiki/Globally_Unique_Identifier Handle System Namespace and Service Definition;

http://www.ietf.org/rfc/rfc3651.txt Handle System Protocol (ver 2.1) Specification http://www.ietf.org/rfc/rfc3652.txt HTML:

https://www.w3.org/html/

HTTP protocol: https://www.w3.org/Protocols/IRI: https://www.ietf.org/rfc/rfc3987.txt

Linked data: https://www.w3.org/wiki/LinkedDataLSID: http://www.lsid.info/

ORCID: https://orcid.org/

OWL: https://www.w3.org/OWL/Plant Trait Ontology:

https://github.com/Planteome/plant-trait-ontology PURL:

https://en.wikipedia.org/wiki/Persistent_uniform_resourceashare RDF

(W3C): https://www.w3.org/RDF/RDF-S:

https://www.w3.org/TR/rdf-schema/SKOS:

https://www.w3.org/TR/skos-reference/SPARQL:

https://www.w3.org/TR/rdf-sparql-query/URI:

https://www.w3.org/wiki/URIs: https://www.w3.org/TR/url/URN:

https://www.w3.org/urn/UUID: https://www.w3.org/wiki/UriSchemes/uuidXRI

(OASIS): https://www.oasis-open.org/committees/xri/