Pattern-based, modular ontologies have several beneficial properties that lend themselves to FAIR data practices, especially as it pertains to Interoperability and Reusability. However, developing such ontologies has a high upfront cost, e.g. reusing a pattern is predicated upon being aware of its existence in the first place. Thus, to help overcome these barriers, we have developed MODL: a modular ontology design library. MODL is a curated collection of well-documented ontology design patterns, drawn from a wide variety of interdisciplinary use-cases. In this paper we present MODL as a useful resource for the development of high-quality, modular ontologies, discuss its use, and provide some examples of its contents.
The Information Age is an apt description for these modern times; between the World Wide Web and the Internet of Things an unfathomable amount of information is accessible to humans and machines, but the sheer volume and heterogeneity of the data have their drawbacks. Humans have difficulty drawing meaning from large amounts of data. Machines can parse the data, but do not understand it. Thus, in order to bridge this gap, data would need to be organized in such a way that some critical part of the human conceptualization is preserved. Ontologies are a natural fit for this role, as they may act as a vehicle for the sharing of understanding [5].
Unfortunately, published ontologies have infrequently lived up to such a promise, hence the recent emphasis on FAIR (Findable, Accessible, Interoperable, and Reusable) data practices [24]. More specifically, many ontologies are not interoperable or reusable. This is usually due to incompatible ontological commitments: strong-or very weak-ontological committments lead to an ontology that is really only useful for a specific use-case, or to an ambiguous model that is almost meaningless by itself.
To combat this, we have developed a methodology for developing so-called modular ontologies [14]. In particular, we are especially interested in patternbased modules [11]. A modularized ontology is an ontology that individual users can easily adapt to their own use-cases, while still preserving relations with other versions of the ontology; that is, keeping it interoperable with other ontologies. Such ontologies may be so adapted due to their "plug-and-play" nature; that is, one module may be swapped out for another developed from the same pattern.
An ontology design pattern is, essentially, a small self-contained ontology that addresses a general problem that has been observed to be invariant over different domains or applications [9]. By tailoring a pattern to a more specific use-case, an ontology engineer has developed a module. This modelling paradigm moves much of the cost away from the formalization of a conceptualization (i.e. the logical axiomatization). Instead, pattern-based modular ontolody design (PBMOD) is predicated upon knowledge of available patterns, as well as being aware of the use-cases it addresses and its ontological commitments.
Thus, in order to address the findability and accessibility aspects of PB-MOD, we have developed MODL: a modular ontology design library. MODL is a curated collection of well-documented ontology design patterns. The particular research contribution is both the curation and documentation. Some of the patterns are novel, but many more have been extracted from existing ontologies and streamlined for use in a general manner. MODL, as an artefact, is distributed online as a collection of annotated OWL files and a technical report containing schema diagrams and explanations of each OWL axiom. 3The rest of the paper is organized as follows. Section 2 discusses the relevance of this work. Section 3 presents our Modular Ontology Design Library in detail and in Section 4 we conclude and discuss future work.
Pattern-based modular ontology development is not a conceptually new ideainstead, it is a continuation of an already established paradigm. Both modularization of ontologies [17] and pattern-based modelling [4] have been identified as improvements to the ontology engineering process. These concepts have culiminated in mature paradigms (e.g. MOM [14,11] and eXtreme Design [16,1]), both having been used in large-scale projects (e.g. GeoLink [15] and VALCRI [3]). However, the ontology engineering community, especially those that utilize patterns, have indicated an increased need for better tooling support [7,2], of which there are two complementary aspects: a dedicated development environment and a critical mass of Ontology Design Patterns (or ODPs for short). 4There is already a prototype that begins to address the need for a dedicated development environment for pattern-based ontologies [6]. It also provides a set of hard-coded patterns that were extracted (at the time of development) from the ODP Portal. 5 However, having the pattern library tightly coupled with the tool is disadvantageous for future development. Indeed, decoupling the tool is desirable, for a number of reasons, as follows.
-Remove the onus of pattern development and upkeep off of the tool developer. -Enable community driven improvements and tailoring of the library to the end-users use-cases. -Enable plug-and-play pattern libraries for different domains, etc.
On the other hand, MODL also addresses the crucial need for a critical mass of ODPs. One may argue that this critical mass exists in the form of the ODP portal. Unfortunately, though, it has suffered under the weight of its own mission. Community enforced quality control has not succeeded in providing a ready-touse suite of quality patterns for use across multiple domains.
Furthermore, while the quality of a set of patterns is largely subjective, MODL strives for consistency in documentation, uses best practices [13,10], and limited ontological commitments. In some cases this required polishing extant documentation, writing it from scratch, and tweaking or detecting errors in the formalization. We also include all new schema diagrams [12] following a single paradigm and style.
MODL therefore addresses, in some fashion, both aspects of improving tooling support. In turn, we expect this to lower the barrier of entry to PBMOD, which in turn lowers the barrier of entry for wider adoption semantic web technologies in application areas.
In this section, we present in detail MODL. Section 3.1 explains our methodology and the organization of MODL, Section 3.2 provides a brief overview on the anticipated usecases of MODL, Section 3.3 provides an example pattern that has been excerpted from the documentation (some of the language and structure, e.g. subsections, have been adapted to fit this paper format), and finally, Section 3.4 provides information pertaining to accessibility, sustainability, and more.
MODL is a curated collection of well-documented ontology design patterns. MODL, itself, can be considered to be the combination of two artifacts, the collection of patterns, specified in OWL, and the accompanying documentation. The separation is a little fuzzy, as the OWL serialization is also heavily annotated for convenience. The mission of MODL is to make patterns both findable and accessible. Therefore, it is of utmost importance that every pattern therein is thoroughly documented. One drawback of the ODP Portal is that there are no guidelines provided for documenting the patterns and, during submission, a form is provided with many optional, ill-defined fields. That is not to say all of the patterns documented therein are poorly documented-some patterns did indeed have thorough documentation. Indeed, we would like to emphasize that the main contribution of MODL is not the patterns in and of themselves. The ODP portal and many of the included patterns are well-known, well-used, and grounded in literature. Where possible, we preserved these efforts, from either the portal or associated publication, and corresponding credit is given in the MODL documentation. Links to ancestor patterns are included in both the annotations and documentation.
However, for many of the patterns included in MODL, we needed to fill some gaps. For this we have elected to follow the guidelines set forth in [13]. These guidelines are a result of a community wide survey that ranks the perceived importance of ten different components of ODP documentation. For our purposes, we have chosen to include the top seven. The schema diagrams for our documentation were manually created using the algorithm found in [12,21]. We elected to use a simplified visual syntax that conveyed relations between concepts and also contains visual cues for identifying concepts that should be used as hooks into the ODP. In this case, a "hook" is some concept that is not fully fleshed out by the pattern, but recognizes that there is some relation at some level. This hook can be another pattern, a module, or a stub (described in more detail later).
The provided OWL files for each of the patterns are annotated with the Extended Ontology Design Pattern Representation Language (OPLa)8 [10]. This allows us to embed provenance metadata (e.g. where did this pattern originate?) or provide pointers to related patterns (e.g. generalizations or specializations of the pattern) in annotations.
Finally, each pattern uses the namespace associated with the persistent URI for this resource 9 . However, the patterns contained inside of MODL are intended to be used as templates [8]. Further, the patterns in a MODL-like pattern library are meant to be local and the collection bespoke to the domain. MODL itself is meant as both example and seed. As such, the pattern URIs are not intended to be resolvable. By instantiating a pattern or making a module, the original pattern namespace becomes inconsequential. However, we acknowledge that this may be a perspective that runs counter to some established view points; thus, as MODL matures, we intend to include redirects to landing pages (e.g. using WiDoCo or similar) in the purl service via content negotiation, as it will certainly further improve usability.
Table 1 lists the patterns included in MODL. They have been loosely organized into five categories: metapatterns; organization of data; space, time, and movement; agents and roles; and description and details. Metapatterns This category contains patterns that can be considered to be "patterns for patterns." In other literature, notably [4], they may be called structural ontology design patterns, as they are independent of any specific context, i.e. they are content-independent. This is particularly true for the metapattern for property reification, which, while a modelling strategy, is also a workaround for the lack of n-ary relationships in OWL. The other metapatterns address structural design choices frequently encountered when working with domain experts. They present a best practice to non-ontologists for addressing language specific limitations. In general, these patterns are not meant to be truly instantiated. One use of these patterns would be to utilize their axioms as a guide. Organization of Data This category contains patterns that pertain to how data might be organized. These patterns are necessarily highly abstract, as they are ontological reflections of common data structures in computer science. The pattern for aggregation, bag, or collection is a simple model for connecting many concepts to a single concept. Analogously, for the list and tree pattterns, which aim to capture ordinality and acyclicity, as well. More so than other patterns in this library, these patterns provide an axiomatization as a high-level framework that must be specialized (or modularized) to be truly useful. Space, Time, and Movement This category contains patterns that model the movement of a thing through a space or spaces and a general event pattern. The semantic trajectory pattern is a more general pattern for modelling the discrete movements along some dimensions. The spatiotemporal extent pattern is a trajectory along the familiar dimensions of time and space. Both patterns are included for convenience. Agents and Roles This category contains patterns that pertain to agents interacting with things. Here, we consider an agent to be anything that performs some action or role. This is important, as it decouples the role of an agent from the agent itself. For example, a Person may be Husband and Widower at some point, but should not be both simultaneously. These patterns enable the capture of this data. In fact, the agent role and participante role patterns are convenient specializations of property reification that have evolved into a modelling practice writ large. In this category, we also include the name stub, which is a convenient instantiation of the stub metapattern; it allows us to acknowledge that a name is a complicated thing, but sometimes we only really need the string representation. Description and Details This category contains patterns that model the description of things. These patterns are relatively straightforward, models for capturing "how much?" and "what kind?" for a particular thing; patterns that are derived from Winston's part-whole taxonomy [23]; a pattern extracted from PROV-O [18], perhaps to be used to answer "where did this data come from?"; and a pattern for associating an identifier with something.
There are two different ways to use MODL-for use in ontology modelling and for use in tools. In both cases, MODL is distributed as a ZIP archive of the patterns' OWL files and accompanying documentation. In the case of the Ontology Engineer, it is simply used as a resource while building an ontology, perhaps by using Modular Ontology Modelling or eXtreme Design methodologies. For the tool developer, we also supply an ontology consisting of exactly the OPLa annotations from each pattern that pertain to OntologicalCollection. As OPLa is fully specified in OWL, these annotations make up an ontology of patterns and their relations. One particular use-case that we foresee is a tool developer querying the ontology for which patterns are related to the current pattern, or looking for a pattern based on keywords or similarity to competency questions. -O). Yellow boxes are concepts. Light blue boxes with a dashed border are external to both the pattern and MODL that the developer may want to also make into a module. ontology. At the pattern level, we do not want to make the ontological committment to a full-blown ontology. It suffices to align a sub-pattern to the core of PROV-O. [18] The EntityWithProvenance class is any item of interest to which a developer would like to attach provenance information. That is they are interested in capturing, who or what created that item, what was used to derive it, and what method was used to do so. The "who or what" is captured by using the Agent class. The property, wasDerivedFrom is eponymous-it denotes that some set of resources was used during the ProvenanceActivity to generate the EntityWith-Provenance.
Persistent URI The persistent URI for this resource is https://archive. org/services/purl/purl/modular_ontology_design_library. The Version 1.0 snapshot and its documentation may be found there. Additionally, it provides helpful links to a technical report and the living data on GitHub, as discussed below. We emphasize that this should not be considered to be a migration of the ODP portal to GitHub, instead, simply where this resource lives, and as such is not meant to supercede or replace the ODP portal.
The canonical citation for this resource may be found on arXiv [22]. The first version of the release has a DOI through Zenodo11 Documentation In addition to this document, we provide in-depth documentation on the library. This documenation contains a primer on ontology design patterns, as a concept, as well as common techniques used in their formalization. Most importantly, for each pattern it provides a schema diagram, its axiomatization, and explanations for each of those axioms. As mentioned in Section 3.1, each pattern is thoroughly annotated with OPLa which provides further documentation on its use and provenance.
Sustainability & Maintenance MODL straddles the realms of dataset and software library; the resource is essentially a snapshot of data that lives. Due to this potential for change, we intend to maintain MODL analogously to a software project. Indeed, while the snapshots will be distributed as ZIP archives, the living data is (at the time of this writing) hosted on GitHub. 12 The Data Semantics Laboratory13 will host MODL's snapshots and appropriate documentation indefinitely. The authors plan to drive further development of needed or requested patterns. Furthermore, by using Git14 we inherit mechanisms for tracking issues and versions and incorporating such community contributions into future releases.
License Information This resource is released under the Creative Commons Attribution 4.0 International Public License the details of which can be found online. 15 A copy of license text is included in the repository.
MODL is a curated collection of well-documented ontology design patterns. We have created this resource to meet a community-recognized need for tooling infrastructure for ontology engineering. In particular, this resource makes ontology design patterns both findable and accessible, shows how they are interoperable, and promotes their reuse. Furthermore, we posit that future ontologies reusing these patterns will promote their interoperability and reuse.
The next steps are many, as MODL is a multifacted, foundational resource. We have identified several patterns that we deem necessary for covering additional frequently encountered modelling needs, e.g. a process pattern or patterns. In addition, there are many alternative patterns that could be considered for future releases. As mentioned in Section 3.1, we also want to further flesh out the documentation with respect to [13], as well as provide individual landing pages describing the ODPs. One future use case that we foresee for this resource is the mapping of competency questions to example SPARQL queries, which maybe could be used as a gold-standard training set for an automated translator. Also mentioned in Section 3.1, we intend to work closely with the digital humanities community for their knowledge representation needs. Finally, we have noted the extreme importance of working closely with tool developers; there is ongoing work to create a Protégé plug-in that utilizes MODL as a base for modular ontology modelling, as inspired by [6,20]. Furthermore, we wish to explore automating the creation of a MODL-like resource. That is, provide a set of scripts or instructions that allow developers to create their own local repository of their own frequently used patterns. Finally, we wish to layout a template for describing MODL-like resources using the Data Catalog Vocabulary 16 and Schema.org's Dataset. 17
Acknowledgement. Cogan Shimizu acknowledges support by the Dayton Area Graduate Studies Institute (DAGSI). Quinn Hirt acknowledges funding from the Air Force Office of Scientific Research under award number FA9550-18-1-0386.