SIMONE: Semantic Representation of Model Outputs for Scientific Knowledge Graph Enrichment

SIMONE: Semantic Representation of Model Outputs for Scientific Knowledge Graph Enrichment Felipe Vargas-Rojas[0000−0002−3530−7964], Vincent Armant[0000−0001−5797−7734], and Isabelle Mougenot[0000−0002−1287−3269] ESPACE-DEV, IRD, Université de Montpellier, Université de Perpignan, Université Antilles, Université de Guyane, Université de la Réunion, Montpellier, France firstname.lastname@{ird.fr, umontpellier.fr} Abstract. The amount of observational data has increased in part due to the more affordable devices and the open satellite data providers. Diverse organisations and working groups have proposed modelling strategies to structure observational data according to their particular purposes. For instance, the ontology I-ADOPT is used to model the detailed description of experiment variables, whereas the ontology SOSA is used to model sensors, instruments and measurements. However, a vast amount of data lies outside the realm of observed data, as is the case with derived, calculated, inferred, predicted, or simulated data. Although both derived outputs and observations share multiple characteristics (e.g., date, value, units, feature of interest, etc.), to our knowledge, there is a lack of a standard model that considers these similarities when describing derived outputs. To fill this gap, this study explores the various representation requirements and introduces SIMONE, a semantic profile based on the semantics of standards such as SOSA and I-ADOPT. We demonstrate the utility of this modelling strategy with a real-life use case concerning the prediction of species coverage for multiple forest areas in Europe. Keywords: Machine Learning Outputs ·Prediction ·Semantic Profile ·Scientific Data 1 Introduction Derived, calculated, simulated, inferred, and predicted data correspond to data that was produced as an output of a given procedure, method, or model and that differ from data collected as part of an observation or measurement. Examples of procedures include: a machine learning model, a simulation, a statistical model, a mathematical formula along with other forms. For the remainder of the paper, we will use the term “derived outputs” to encompass all the above-mentioned kinds of data, and the word procedure as the mechanism to produce such outputs. Derived outputs could be considered as “secondary data” or transformed data, in the sense that they are derived from a procedure applied over “primary data”. 2 Vargas-Rojas et al. Derived outputs are often the only available data provided by laboratories or institutions due to privacy policies and research interests. Paradoxically, the existing knowledge models are mostly intended for describing “primary data”, for instance, sensor observations, surveys, and satellite images. Across diverse scientific domains, model outputs are used to estimate properties of biological and environmental entities (e.g., the amount of deforestation in a forest area). As an example, the domain of remote sensing employs deep learning algorithms to identify objects and calculate indicators, which enable the generation of analytical tools such as soil and biomass maps [23] . However, to our knowledge, there is a lack of a standard way to model a claim such as “the model xpredicted that the glacier surface area of the Montblanc is 159 (km2) in 2008”. Common ways to share derived outputs include: (i) paper reports containing figures, data aggregations, and authors’ analysis, (ii) benchmarks aiming to position a topic and facilitate approach comparison, (iii) extra attributes in metadata schemas for dataset description, often without any particular semantics and at the same level of primary attributes. Examples of dataset sharing portals include: DataTerra [12], Dataverse [5], Google Datasets [4], and so on. We point out that the the sharing methods and models are somehow disconnected from the original problem, and no annotations are provided to indicate, in a machine-readable fashion, the entity of interest and the context in which that derived output takes place. These limitations exacerbate the reproducibility crisis [2] and make it difficult to reuse outputs, despite reusability being one of the goals of the Findable, Accessible, Interoperable, and Reusable (FAIR) principles [29]. In this work, we consider that we can reuse knowledge models from primary sources such as observations, to establish a standard manner to share model outputs. Concretely, the well-known ontology for Sensors, Observations, Samples, and Actuators (SOSA) [13] incorporates the notions of feature of interest, method used, the observed property, etc, which are widely used and interpretable. In practice, many manual and human analytical steps are required to interpret metadata schemas. This work is motivated by a recent work denominated OneForest Knowledge Base (OneForestKB) [24] and within the context of the European Project Eco2Adapt1. OneForestKB aims to model observational data concerning forestry entities, thus requiring time, geospatial annotations, and multidisciplinary terms. The semantic profile proposed in that study lacks annotations to describe model outputs, which are fundamental to enrich the knowledge base. This study explores the following research question. RQ:How can model outputs be represented considering the observational paradigm so that their exploitation and reuse through knowledge bases can be standardised?. Our contributions include: (i) SIMONE, a semantic profile to structure derived outputs; (ii) a set of mapping rules showcasing the profile’s utility: the outputs are generated from the tool GeoPl@ntNet2(this tool uses a deep learning species distribution 1https://www.eco2adapt.eu/ 2https://geo.plantnet.org/ SIMONE: Semantic Representation of Model Outputs 3 model), transformed to a labelled-graph form and linked to existing entities in the OneForestKB; (iii) a set of competency questions enabling to explore different functionalities of the semantic model. This work is organised as follows: section 2 details the related work, section 3 describes and compares three main ontologies and introduces SIMONE, our semantic profile. Besides, section 4 presents a use case of SIMONE, taking into account real-world data and including mapping rules to the target model. Finally, section 5 exposes the conclusions. 2 Related Work Fig. 1: Procedure aspects We use the Figure 1 to establish a common vocabulary enabling us to explain the related work. A procedure is defined in SOSA as ‘a workflow, protocol, plan, algorithm, or computational method specifying how to make an Observation, create a Sample, or make a change to the state of the world (via an Actuator)”. A procedure is a set of instructions that can be implemented in different languages (e.g., Python, R, RDF, XML, ...). This aspect is refereed in the figure as the procedure content. The procedure can be accompanied by metadata such as identification and a natural language description, as well as catalogue annotations, etc. How the procedure was implemented, calibrated, or trained is part of the aspect procedure generation. Moreover, a procedure is executed within a specific context and with input data, thereby producing an output. Finally, we highlight that the outputs can also be linked to an existing knowledge graph. Procedures and methods are terms widely used to describe scientific experiments detailing how an experiment was conducted. For instance, Zhao et al. [30] propose a metadata framework for experiment reports. However, in this work, we are mostly interested in computational and statistical procedures. The provenance ontology (PROV [15]) describes metadata for annotating activities, entities, and agents in an upper-level fashion. Results (i.e. outputs) can be modelled as prov:Entity along with the property prov:wasGeneratedBY. 4 Vargas-Rojas et al. The PROV ontology have been extended to annotate workflows and pipelines (e.g., ProvWorkflow [16]). This extension focus on describing the workflow itself. Whilst such description clarifies how an output was obtained, interlinking and output annotations are overlooked. For instance, spatio temporal aspects of the outputs in relation to existing biological entities. By using PROV, we may add unnecessary navigation complexity considering our main goals. Similar studies such as PROV-ML [22] and Schlegel et Sattler [21] fall under the same limitations. In a recent work (Schembera et al [20]), the authors merge two ontologies with the purpose of annotating algorithms and mathematical models using an uniform ontological representation. Although such representation may enrich a procedure metadata, the description of model outputs and their interlinking with existing entities is not taken into account. Whilst the motivations for this work are machine learning models, data can also be derived from mathematical calculations. The idea of describing and computing a procedure content using Semantic Web technologies has been explored in different studies (QAVAN[25], RDF-OpenMath[28], QB-equations[3], ...). These studies introduce a graph enrichment layer, which links unknown properties of entities to a specific procedure that can be executed to generate the missing facts. Here, the procedure is a source of mathematical knowledge, indicating how to produce a value that enriches the graph. Therefore, enabling the new derived data for query-answering. Bear in mind that for this study, we focus on data treated before their integration to a knowledge base, not in automatic generation. Notably, these approaches are intended for simple mathematical computations and do not consider machine learning or simulation models. Other studies focus on annotating the execution context, including the Function Ontology (FO [6]) and a conceptual model for scientific computations [19]. Conversely, they do not detail the procedure content steps but their metadata. None of the mentioned approaches pays enough attention to the output description, whereas the context execution approaches disregard the interlinking requirement. SOSA [13] is a W3C recommendation for sensors, actuators, and measurements. This vocabulary has gained attention in many scientific fields, including earth and environmental sciences [1] as well as ecology and biology. The initial focus of this ontology is the concept of observation. Yet, it offers specific annotations for data derived from some procedure through the property sosa:usedProcedure, whose range is sosa:Procedure. Along with the notion of features of interest, SOSA is a valuable resource for linking model outputs with existing entities. However, elaborated outputs involving multiple entities could require additional modelling annotations. For instance, the root height of a plant involves two particular entities: the root and the plant; this kind of setting leads to issues using merely SOSA. Later in this work, we will provide a more detailed explanation of how to address this representation issue. This ontology have been used to model indicators such as the NDVI and image pixels [27]. Besides, ontologies on primary data such as I-ADOPT [17] and the Crop Ontology (CO) [18] SIMONE: Semantic Representation of Model Outputs 5 also include notions to facilitate the annotation of derived outputs, as we will detail in the remainder of this work. 3 Methods This section explores the different strategies we use to construct SIMONE. Initially, we analyse three related ontologies, and then we define a list of necessary concepts and relationships as a base to annotate derived outputs. We compare the analysed ontologies against our list of needed terms, highlighting why they are complementary and necessary. We finalise detailing the semantic profile. 3.1 Analysed Ontologies We selected three ontologies from the state-of-the-art to analyse and compare them, as they offer several notions, concepts, and relationships that match our profile. I-ADOPT [17]: an ontology that provides a standard manner to describe complex variables, notably in scientific fields including biodiversity, ecology, and environment. A variable is the base concept and consists of two mandatory fields: the involved property and the object of interest. A basic variable can be: “the air daily maximum temperature”, in this case the air is the object of interest, whilst the temperature corresponds to the property, the example adds an element, which is a statistical notion of maximum. I-ADOPT enables this condition using the relation hasStatisticalModifier. More contextual information and constraints can be added using I-ADOPT. In our comparison, this framework offers the more complete set of entities and relationships to represent detailed variables. SOSA [13]: an ontology to describe sensors, observations, samples, and actuators. This ontology is a W3C recommendation and one of the most used standards in diverse domains. It is based on the observation paradigm; the central concept is an observation accompanied by the time, the feature of interest, the measurement in numerical terms, and the observed property. The notion of space is often associated with the feature of interest, as that concept can involve a specific location. However, the standard do not detail too much about that dimension. One example of a claim that can be represented with SOSA is: “a sensor measured that the solar radiation in a green house was of 340 W/m2at 2022-01-31T12:00”. The given example can be represented using SOSA in RDF Turtle as follows (prefixes can be found in Annex A): ex:observ1 asosa:Observation, sosa:madeBySensor ex:tempSensor, sosa:featureOfInterest ex:greenHouse, sosa:hasResult [ qudt:numericValue 340, qudt:unit unit:W−PER−M2 ], sosa:date "2022−01−31T12:00:00"^^xsd:dateTime, sosa:observedPropery ex:solarRadiation. 6 Vargas-Rojas et al. The given example also uses the unit ontology QUDT [11], which aims to represent quantity values. The QUDT ontology is often used along with SOSA given their lack of unit of measurement terminology. SOSA introduces additional concepts such as sampling and actuators. In this work, we pay attention to the concept of sosa:Procedure that allows us to model the method from which an observation was derived. We exploit this possibility in SIMONE. Crop Ontology (CO) [18]: an ontology but also a set of services developed by several centres of The Consultative Group on International Agricultural Research (CGIAR). These services enable the linking and curation of traits3to facilitate the discovery of genotypic and phenotypic data related to a given trait. In addition, these services are integrated with plant breeding information systems. The main entity in this ontology is the trait, which is specialised as a variable. A trait can be seen as a pair entity + property, whilst a variable is compound of a trait + method + scale. For instance, in CO the variable GFeC_M_mgkg represents the claim “the trait iron content measured using the method standard iron content dry ash having as scale mg/kg”. CO includes the notion of method, which is of interest to us; however, it is mainly at a top-level description, neglecting the concrete model or instruments. 3.2 Main entities and coverage of existing ontologies Concept SOSA I-ADOPT Crop Ontology Refereed variable (the output is about what?) observed property observedProperty hasProperty quality involved entity - hasObjectOfInterest entity context - hasObjectContext - constraints - hasConstraint - Result/Inference/Derivation/Prediction (output description) value - - - unit (may also be part of a variable) - - scale/unit type - - - Feature or Object of interest (the output describes/estimates what object?) feature/object hasFeatureOfinterest - - Method (the output was derived using what method? method usedProcedure - hasMethod accuracy - - - type - - type Table 1: Main entities participating in the annotation of outputs compared across different ontologies 3this notion is similar to the one of a variable or observed property SIMONE: Semantic Representation of Model Outputs 7 Table 1 exposes our conception of the main entities necessary to annotate derived data. Every concept is grouped in four categories, and compared to three referential ontologies in related domains. The table includes the possible annotations that can be borrowed from these ontologies in order to cover the proposed entities. We describe the four proposed categories in reference to the output object. Refereed variable: an output is about something. [17] defines a varible as “a description of something observed or derived”. The notion of variable is welladdressed by the ontologies I-ADOPT and the Crop Ontology [18]. In this category, different terminologies could be related; for instance, SOSA mentions that an observation is about an observed property and does not elaborate on the notion of a variable, which can be seen as a contextual description of a property. Variables may refer to objects bound by a target entity; for instance, the “root height” of a plant involves the entity root and its property height. The pair (entity-property) becomes a variable in the sense that they together describe information about a plant. Notice that we distinguish an entity part of a variable (e.g., the root) from the object of interest (e.g., a plant). Result/Inference/Derivation/Prediction: Depending on the type of process, a resulting value can adopt different names. The output is composed mainly of a value, which can be either numeric or text. This output can also involve a unit of measurement. However, in practice, the unit can also be related to the notion of a variable or method, since a model typically provides outputs in a particular unit or scale. As we can see, I-ADOPT does not cover this concept since its focus is on the variables, whilst the Crop Ontology incorporates a notion of unit but lacks annotations for the obtained value. SOSA incorporates the notion of values and units but lacks information about the type since the notion of observation is dominant in the standards. This comparison shows that the type of output is disregarded for the studied ontologies. Feature or object of interest: The output is estimated for describing a particular object. In SOSA, that information is referred to as a feature of interest: “the thing whose property is being estimated or calculated in the course of an Observation to arrive at a Result” [13]. Although I-ADOPT mentions the concept of an object of interest, it is attached to a variable and does not represent an independent object. Method: The method is a central concept in this study since it describes the manner in which an output was generated. Although several metadata can be incorporated in this part, we focus on the essential terminology, such as the naming of the given method and a reference or link to obtain more details about it. The type of model also plays a critical and informative role; we also provide a categorisation of the different methods later in this work. Finally, models have 8 Vargas-Rojas et al. an accuracy level, which differs from observations that we can assume as reliable information. Summary. By studying different ways to describe variables and observations, we can conclude that none of the referential ontologies alone can encompass all the essential concepts necessary to describe model outputs. It is worth noting that they are complementary and contribute many important notions and conceptualisations, although they are intended for different goals. 3.3 Semantic Profile Fig. 2: Semantic Profile unifying SOSA and I-ADOPT to structure derived outputs. Relationships at the observation collection level are also valid at the observation level. Figure 2 displays the proposed profile. For example, the declaration stating that “the model xpredicted that the value for the variable vis uin a context c” can be easily modelled with SIMONE. The main structure of this profile is based on SOSA, in the sense that we cover time, space, principal entity, and the output itself; these decisions are supported by the table 1. Building on the notion of procedure already present in SOSA, we model this dimension and leave it open to add extra annotations, as we will detail later. Moreover, we link the ontology I-ADOPT to SOSA through the relationship sosa:observedProperty, which range in this profile is a I-ADOPT variable. This key decision was motivated by the fact that in ecology and environmental science, the variables can be complex and SIMONE: Semantic Representation of Model Outputs 9 require additional entities as well as constraints on those entities. Finally, the outputs are often given in a particular unit of measurement, which we model using the ontology QUDT [11]. We also exploit the notion of observation collection in order to factorise specific properties that are redundant in the observation level. Having established the above-mentioned structural bases, in a second step, we explore different vocabularies to reuse key annotations. This step does not modify any structural aspect. For instance, Wikidata [26] is the most used public knowledge graph; its primary purpose is general knowledge, thus well-known models such as AlphaFold —a model developed by the team DeepMind in Google to predict the structure of proteins— is presented in Wikidata with the ID Q608275954). Annotations from Wikidata relevant for this work are shared in Table 2. Others well-known vocabularies, including Schema.org and Dublin Core, are also suitable for incorporating extra descriptions. Property Value inception 2018 has use protein structure prediction instance of artificial intelligence model developer Google DeepMind programmed in Python software version identifier 2.3.2 Table 2: Wikidata annotations for the model AlphaFold (Q60827595) 4 Use Case: OneForestKB with Pl@ntNet Model Ouputs This section presents a real-life use case about the formalisation of outputs derived from a deep learning model. Data Enrichment of European Living Labs. Living Labs are open innovation ecosystems in real-life and experimental environments fostering co-creation among the main actors of the Quadruple Helix Model, namely: Citizens, Government, Industry and Academia [10]. Within the context of the EU-project Eco2Adapt the model outputs for seven different labs are formalised. These living labs are delimited zones within a EU country. The geospatial representation of these living labs uses formats such as WKT or GeoJSON, these shapes are used as inputs for prediction models. One goal of SIMONE is to offer a standard manner to enrich living labs and their entities with outputs from different models. Moreover, we obtain the model outputs from a deep learning model for species distribution (DeepSDM) refer to [8, 7, 14] for further details. The Pl@ntNet team has created a dedicated site for the information associated to the different living 4https://www.wikidata.org/wiki/Q60827595 16 Vargas-Rojas et al. A Global Prefixes Listing 1.1: Global Prefixes PREFIX species:<http://purl.org/eco2adapt/species#> PREFIX eco−labs:<http://purl.org/eco2adapt/livinglab/> PREFIX dwc:<http://rs.tdwg.org/dwc/terms/> PREFIX iadopt:<https://w3id.org/iadopt/ont/> PREFIX ex:<http://www.example.org/> PREFIX sosa:<http://www.w3.org/ns/sosa/> PREFIX qudt:<http://qudt.org/schema/qudt/> PREFIX unit:<http://qudt.org/vocab/unit/> PREFIX xsd:<http://www.w3.org/2001/XMLSchema> B Competency Questions Listing 1.2: CQ1 SELECT ∗ WHERE { ?coll asosa:ObservationCollection ; sosa:hasFeatureOfInterest eco−labs: BordeauxLL; sosa:usedProcedure ex: method_PlantNet−06−2025 ; sosa:hasMember ?obs. # output ?obs sosa:hasSimpleResult ?r; sosa:observedProperty ?var. # species ?var iadopt:hasObjectOfInterest ?species . ?species dwc:specificEpithet ? specificEpithet. } ORDER BY DESC(?r) LIMIT 10 Listing 1.3: CQ2 SELECT ?coll ?family (COUNT(?family) AS ?count) (SUM(?r) AS ?sumR) WHERE { ?coll asosa:ObservationCollection ; sosa:hasFeatureOfInterest eco−labs: BordeauxLL; sosa:usedProcedure ex: method_PlantNet−06−2025 ; sosa:hasMember ?obs. # output ?obs sosa:hasSimpleResult ?r; sosa:observedProperty ?var. # species ?var iadopt:hasObjectOfInterest ?species . ?species dwc:family ?family. } GROUP BY ?coll ?family ORDER BY DESC(?sumR) LIMIT 10 SIMONE: Semantic Representation of Model Outputs 17 Listing 1.4: CQ3 SELECT ?species (COUNT(∗) AS ?count) WHERE { ?coll asosa:ObservationCollection ; sosa:hasFeatureOfInterest ?livinglab; sosa:usedProcedure ex: method_PlantNet−06−2025 ; sosa:hasMember ?obs. # output ?obs sosa:hasSimpleResult ?r; sosa:observedProperty ?var. # species ?var iadopt:hasObjectOfInterest ?species . ?species dwc:specificEpithet ? specificEpithet. FILTER(?r> 50)} GROUP BY ?species HAVING (?count >= 3) ORDER BY DESC(?count) Listing 1.5: CQ5 SELECT DISTINCT ?livinglab ?procedure ? property WHERE { ?coll asosa:ObservationCollection ; sosa:hasFeatureOfInterest ?livinglab; sosa:usedProcedure ?procedure ; sosa:hasMember ?obs. # output ?obs sosa:observedProperty ?var. # species ?var iadopt:hasObjectOfInterest ?species . ?var iadopt:hasProperty ?property. } Listing 1.6: CQ4 SELECT ?family (COUNT(∗) AS ?count) WHERE { { SELECT DISTINCT ?family ?livinglab WHERE { ?coll asosa:ObservationCollection ; sosa:hasFeatureOfInterest ?livinglab; sosa:usedProcedure ex:method_PlantNet−06−2025 ; sosa:hasMember ?obs. # output ?obs sosa:hasSimpleResult ?r; sosa:observedProperty ?var. # species ?var iadopt:hasObjectOfInterest ?species. ?species dwc:family ?family. FILTER(?r> 50)} } } GROUP BY ?family HAVING (?count >= 3) ORDER BY DESC(?count)