The I-ADOPT Modeling Workshop II

RDA InteroperAble Descriptions of Observable Property Terminology WG (I-ADOPT WG)

�Core members:

Barbara Magagna, GO FAIR Foundation, NL

Gwenaëlle Moncoiffé, BODC, UK

Anusuryia Devaraju, CSIRO, AU

Maria Stoica, University of Colorado, US�Sirko Schindler, German Aerospace Center, DE

Alison Pamment, Centre for Environmental Data Analysis, UK

My wished output for these workshop

My wished output for these workshop

My wished output for these workshop

My wished output for these workshop

My wished output for these workshop

My wished output for these workshop

My wished output for these workshop

My wished output for these workshop

What I expect to happen after the workshops

• Get a common understanding of all involved models, ask if necessary for clarification
• Don’t dominate the discussion, let everybody have their say
• Try to be goal-oriented in discussions
• Complex discussions should be parked in github issues, and finalized after the workshop
• Define for each modelling block what you want to achieve
• Work in teams, define a teamleader and a notetaker
• Document your process in the notes
• Use Mattermost to discuss with online people, also to work together after the workshop
• Discuss how to represent well defined I-ADOPT variables and OMS extensions
• Report back to the plenary your findings

​

Some good practices for this workshop

Find the reference document for all models here�

I-ADOPT alone:

​

• Define the I-ADOPT variable using this template
• Discuss about an I-ADOPT variable using the Example GitHub issues

​

I-ADOPT & OMS:�

• Define the I-ADOPT variable & OMS using this template or google sheet
• Discuss about an I-ADOPT variable & OMS using the OMSmodelling GitHub issues

​

GitHub repositories and templates to use

I-ADOPT variable modelling tips

​

​

​

​

​

​

​

• Find other examples here:
• Demo modelling

Generally, I-ADOPT is a good starting point but …

it cannot yet solve all use cases, thus needs refinements and extensions

​

I-ADOPT should remain usable also independently of OMS

​

• Some clarifications about how I-ADOPT aligns with OMS
• Some clarifications about the matrix (incl. false disagreements)
• Some new application design records to be discussed
• Some general questions

​

Key outcomes from workshop I

1. Without doubt I-ADOPT can be used to FAIRify observable property
2. I-ADOPT variable refers always to the ultimate observable property
3. The proximate observable property could be represented following the I-ADOPT pattern
4. There is no clear pattern how to relate the featury type to a specific description component (tried to verify looking at the ContextObject in the challenge variables)

​

I-ADOPT vs OMS

1. Matrix should be kept simple, rather an element, a medium than an object. So water, instead of water body.�Open: What is the ultimate aim for this refinement? Is it related to wish to find a clear dependency between one fixed role within I-ADOPT and feature type?�Do we need to have a recommended controlled list of matrices?
2. Can a phase be a matrix or is it a constraint of the matrix? Rather the latter!
3. We should relax the idea that matrix needs to be defined before we add the ContextObject

False disagreement: hasMatrix is a sub-property of hasContextObject -  the instances used for matrixes must also be instances of the context objects (see  Charly Coussot’s remark). There is no problem with it, as the range are instances of Entity, which can be playing roles as a matrix or a context object

Matrix

1. Systems for allowing multiple Object of Interests or multiple Matrices
2. Describing Products
3. Documenting used pattern
4. Expressing baselines

​

Application Design Records

1. Symmetric systems with participants that have no specific roles, like distance between two objects

​

​

​

​

​

• Asymmetric systems with participants having specific roles; allowing the description of ratios where no matrix can be used�or fluxes between 2 environmental�compartments (from – to), blank node�would be the interface between those

​

Systems

​

​

Using other properties to describe additional aspects of

the measurement, using observing procedure from OMS, or ISO 19131

(see options)

Extensions beyond I-ADOPT for Products

Documenting the pattern could be useful for associating the logic used to decompose to the variable description; useful for service development?

​

Could be machine-readable or as a text information.

Documenting the Pattern used

organism

Constraining the property

​

​

​

versus

​

​

Using system for object of interest

Expressing baseline

• Are we (domain vocabularies) prepared to change existing variable descriptions after deciding on clear patterns?
• How useful are I-ADOPT variables in metadata when Data streams are described via FROST API? (metadata vs data representation)
• How should we make Constraints more explicit?
• Do we agree that I-ADOPT is focused on the ultimate measurement?�Example: Nitrate concentration as N�Nitrate concentration = ultimate measurement�N concentration = proximate measurement�Should we make it clear that these are connected in OMS?

Some general questions

• Accept as input a sentence provided by the �observer
• Check if existing description exists on various �platforms, if not:
• Decide which pattern to follow
• Ask for feedback to correct interpretation
• Decompose the variable into description �components according to pattern and visualize it
• Find appropriate concepts to annotate the description components
• Provide RDF representation of the variable
• Visualize the RDF representation in a skosmos-like fashion
• More?

​

​

Requirements for the I-ADOPT service

• Is LLM-based technology the only option? What about deterministic methods?
• Can we use patterns to follow?
• How many variables do you need to start?
• How can papers about variables help?
• We need first to get rid of ambiguities
• What is the timeline? Can you first concentrate on other steps?

​

​

I-ADOPT service – how to start