Knowledge graphs (KG) are an established method for heterogeneous data integration and have begun powering complex software agents. However, it is important to understand where the data in the knowledge graph originates, especially within the context of synthetic research agents and other trustworthy AI systems. In this paper, we propose an ontology design pattern for tracking the provenance and context of computational observations, as well as a proposing a supporting, simplified conceptual framework for modeling abstract and concrete versions of the same underlying notion.
The remainder of the paper is organized as follows. In the next section, we discuss background and related work. Section 3 provides a brief discussion on a basic, conceptual pattern for modeling abstract and concrete concepts for the same notion. In Section 4 we present our pattern and provide its formalization. Finally, in Section 5, we conclude with future work.
There is some existing literature that focuses on how to capture the results of modeling and simulation software. As far as the authors are aware, there is not directly corresponding work for directly modeling computational observations. Below, we describe some tangential work that could be used in a limited fashion, and how it relates to our pattern described in Section 4.
SOSA/SSN (The Sensors, Observations, Sampling, Actuators Ontology and Semantic Sensor Network Ontology [3]) are W3C Recommendations for modeling how observations are generated from sensors. While the notion of a sensor, within these ontologies, is left intentionally ambiguous and can, indeed, be used to represent a piece of software (e.g., for simulation or forecasting purposes), it is awkward to do so, due to requirements on phenomenon and result times of observations – and whether or not a software producing a dataset is really an observation at all. Secondly, SOSA/SSN does not provide a mechanism for modeling aspects of the software or hardware, which this pattern provides.
ML-Schema [4] was proposed by the W3C Machine Learning Schema Community Group to capture the provenance of machine learning data sets, algorithms, models, software implementations, and model runs for machine learning experiments. While ML-Schema captures the computational workflow associated with an ML experiment, it does not conceptualize a “model” as a surrogate for a real world phenomenon and is instead focused on capturing the type of machine learning methodology as a model. Also, because it was developed primarily as a schema for ML experiments, it lacks the generality of a ontology pattern based approach.
The Data Transformation Pattern [5] describes how data is transformed via diferent numerical operations (a schema diagram for the pattern is shown in Figure 1). This pattern focuses on the dataset level, rather than the specific data within them, for tracking how the datasets were transformed, what – or whom – performed those actions, and which datasets were used to generate or derive the new dataset. The Computational Observation pattern, instead, focuses on how computational models generate specific data (e.g., computational observations).
The Computational Environment pattern [6] is used to model the hardware and software configurations where a particular piece of code may be implemented and executed. Its focus is not on the metadata of the results of that execution, but instead on providing a human and machine-interpretable way of exchanging (arbitrary) configuration information. Indeed, we reference this concept in our own pattern.
It is frequently desirable to model a particular concept and its abstraction. That is, the diference between an algorithm and the execution of that algorithm. The Descriptions and Situations (DnS) [7] framework is one way to accomplish this. However, DnS can be quite challenging to approach, especially for those without significant ontology engineering experience or foundations in logics. It furthermore leverages DOLCE [8], a foundational ontology, which may not be compatible with project needs. The following is an alternative, simplified framework by which one can conceptually reason about the description and situation dynamic.
Figure 2 shows a schema diagram for a simplified conceptualization of the Description and Situation dynamic. In summary, a Description exists outside of time – it is the abstraction of a notion; a Situation is an instantiation of that Description that is anchored in space and time.
For example, consider the notion of an algorithm. Loosely speaking, an algorithm is a set of steps that operate on an input to produce an output, for example: long division or, less trivially, normalizing a series of data. Such algorithms, however, exist in the abstract; the executions of them, do not. They are run in particular computational environments, on some hardware, and according to some software implementation. Consider the graphical representation in Figure 3: the Algorithm corresponds to the Description; the Execution corresponds to the Situation; and we split the spatial and temporal aspects of a SpatiotemporalExtent to produce a TemporalExtent and a ComputationalEnvironment. In a more complex scenario, one might also consider an algorithm to have an input or parameter space, where the Execution would have specific inputs and parameters. 3.1. Formalization of the Simplified Framework We provide a brief formalization of this framework.
Description is the abstract representation of a particular concept or notion. This could, for example, be an algorithm or a recipe. Intuitively, the Description is a template.
⊤ ⊑ hasDescription.Description Situation is the concrete instantiation of a particular Description. This could, for example, be the execution of an algorithm or the act of following a recipe. Intuitively, the Situation is a template that has been “filled out.”
The Computational Observation ODP is driven by the interplay between the three core concepts: ComputationalModel, ComputationalModelExecution (CME), and ComputationalObservation. The first two correspond, respectively, to the Description and Situation from Figure 2. That is, a ComputationalModel is an abstract representation of the space of all computational models, and the CME is a concrete instance from that space (e.g., parameters and inputs have been selected). The CME is then comprised of a set of generated outputs: the ComputationalObservations.
The rest of the pattern is relevant metadata important to describing the entire process or pipeline. ComputationalModels are implemented into a codebase (Implementation) and are compiled into executables (Executable). An execution of the ComputationalModel requires that we capture the temporal extent (i.e., when it was executed) and the computational environment (i.e., where it was executed). Below, we provide further descriptions of each concept and its relevant axioms (listed alphabetically).
ComputationalEnvironment is the encapsulation of hardware and software configurations of the computer used to execute the ComputationalModelExecution. This interface may be satisfied by the ODP of the same name, as in [6].
ComputationalModel (CM) is an abstract notion intended to connect the conceptual,
mathematical and algorithmic models as surrogates for real world phenomena that is the intended
(
(
(
CME ⊑ =1 hasTemporalExtent.TemporalExtent
⊤ ⊑ ∀ executedIn.ComputationalEnvironment
⊤ ⊑ ∀ hasParameterInstantiation.ParameterInstantiation
ComputationalObservation (CO) is the core concept of this pattern. Notably, we do not mandate that the CO is an EntityWithProvenance, as it is already directly modeled via the generatesOutput property. Indeed, we specify that it is inverse existential to state that any CO must have been generated by a CME. We also do not specify any particular way to formulate what the value of the CO is, as we want the pattern to be suficiently generalized. Finally, we realize that informedBy is a very informal term – we anticipate that the exact label for the relationship be adapted to a particular use-case; we simply want to use a placeholder to indicate that a relationship exists here.
ComputationalObservation ⊑ =1 informedBy.ComputationalModel
EntityWithProvenance is eponymous; it indicates that the entity in question has desirable metadata, such as who generated the entity, when it may have been generated, and what was used to derive the entity. We recommend using PROV-O [9] to satisfy this interface. Executable is the artifact that can be executed, and is generally produced by a compiler. As such, we indicate that it is an EntityWithProvenance so that this may be captured. We also state that an Executable can only be compiled from exactly one Implementation. Implementation is the formulation of the computational model into some codebase (e.g., the hosting repository). In our axiomatization, we state that the Implementation is an EntityWithProvenance, allowing us to model, for example, contributors. Furthermore, we provide scoped domain and range restrictions for the implements property, as well as state that an Implementation implements ComputationalModels. This axiom can be changed depending on the requirements – it is foreseeable that one to many ComputationalModels can be implemented in the same repository (existentiality), or only one (exact cardinality restriction of 1).
ParameterInstantiation is the set of parameters the defines the, typically mathematical, model space for an execution of a computational model. For instance, in Newton’s Law of Cooling: ̇ = ℎ * ( () − ), the heat transfer coeficient ℎ, objects surface area , and the temperature of an objects surrounding environment would provide part of a ParameterInstantiation needed to understand the results of the execution of a computational model. Additional details such as time step used in solving the mathematical model would also be part of the ParameterInstantiation.
Resource is an arbitrary piece of data that the computational model will require in order to run. These might be data sources or parameters. Note that a ComputationalModel is also a Resource. This allows us to model how ComputationalModels might feed into each other. TemporalExtent is a straightforward concept, representing the length of time that the ComputationalModelExecution would have run. It is, however, left as an interface in the pattern, as we do not want to mandate a particular conceptualization of time. This interface could, for example, be satisfied using xs:duration or the Time ontology [10] for more complex modeling, depending on the needs of the use-case.
Modeling the process or pipeline by which computational observations are generated (i.e., the results from executed numerical models or simulations) is an important aspect of trustworthy data. For example, the adage “Garbage In, Garbage Out” comes to mind. How can we trust operations on unknown data that is untrustworthy? The Computational Observation ODP is an attempt to fill this space. By describing the entire generation pipeline, from the particular resources used to implement a computational model, to the hardware, software, and parameter configurations used in the execution of said computational model we can more readily understand how certain results were achieved in modeling and simulation scenarios.
We furthermore presented a simplified, conceptual framework for discussing abstract and concrete notions of the same underlying concept. That is, the diference between, for example, an algorithm and its execution; or a recipe and the act of cooking. In this way, a computational model and its execution must be similarly modeled.
We have identified the following items as next steps in our work. 1. We intend to instantiate and connect it to instantiations of both the Data Transformation and Computational Environment Patterns, to create a Modeling & Simulation Ontology. 2. The Computational Observation pattern will be added to the next version of MODL (The modular ontology design pattern library – [11]). 3. Create a cross-walk from the Computational Observation pattern to the CodeMeta Project [12].
Acknowledgement. Authors Shimizu and Hitzler wish to acknowledge funding for this work under the National Science Foundation Grant No. 2033521: “KnowWhereGraph: Enriching and Linking Cross-Domain Knowledge Graphs using Spatially-Explicit AI Technologies”. Author Vardeman wishes to acknowledge funding for this work under the National Science Foundation Grant No. PHY-1247316: “DASPOS: Data and Software Preservation for Open Science” and Grant No. 2127548 “CI-Compass”. Any opinions expressed in this material are those of the authors and do not necessarily reflect the views of the National Science Foundation. The authors would also like to acknowledge valuable discussion with David Carral, Gary Berg-Cross, and Michelle Cheatham in the early stages of the pattern’s development. Lecture Notes in Computer Science, Springer, 2003, pp. 689–706. URL: https://doi.org/10. 1007/978-3-540-39964-3_44. doi:10.1007/978-3-540-39964-3\_44. [8] A. Gangemi, N. Guarino, C. Masolo, A. Oltramari, L. Schneider, Sweetening ontologies with DOLCE, in: A. Gómez-Pérez, V. R. Benjamins (Eds.), Knowledge Engineering and Knowledge Management. Ontologies and the Semantic Web, 13th International Conference, EKAW 2002, Siguenza, Spain, October 1-4, 2002, Proceedings, volume 2473 of Lecture Notes in Computer Science, Springer, 2002, pp. 166–181. URL: https://doi.org/10.1007/3-540-45810-7_18. doi:10.1007/3-540-45810-7\_18. [9] S. Sahoo, D. McGuinness, T. Lebo, PROV-O: The PROV Ontology, W3C Recommendation,
W3C, 2013. Http://www.w3.org/TR/2013/REC-prov-o-20130430/. [10] C. Little, S. Cox, Time Ontology in OWL, W3C Recommendation, W3C, 2017.
Https://www.w3.org/TR/2017/REC-owl-time-20171019/. [11] C. Shimizu, Q. Hirt, P. Hitzler, MODL: A modular ontology design library, in: K. Janowicz, A. A. Krisnadhi, M. Poveda-Villalón, K. Hammar, C. Shimizu (Eds.), Proceedings of the 10th Workshop on Ontology Design and Patterns (WOP 2019) co-located with 18th International Semantic Web Conference (ISWC 2019), Auckland, New Zealand, October 27, 2019, volume 2459 of CEUR Workshop Proceedings, CEUR-WS.org, 2019, pp. 47–58. URL: http://ceur-ws. org/Vol-2459/paper4.pdf. [12] codemeta, The CodeMeta Project, https://codemeta.github.io/, ????