Ontology Versioning Framework for Representing Ontological Concept as Knowledge Unit Archana Patela and Sarika Jainb a Institute of Computer Science, Freie University Berlin, Berlin, Germany b Department of Computer Applications, National Institute of Technology Kurukshetra, Haryana, India Abstract Nowadays ontologies are used in everywhere and provide a reusable piece of knowledge about a specific domain. However, those pieces of knowledge are not static and change over the time in order to fulfil the requirements of the different task. So, it is essential that changes in ontologies should be managed very well. Ontology versioning mechanism is used to keep the track of the ontology changes via making the relationship with previous version of the ontologies. Many ontologies encode reality by representing ontological concept as a knowledge unit. Till the date, no work has been started towards to solve the ontology versioning problem when ontological concept store based on the idea of knowledge unit. To overcome this problem, we present an ontology versioning framework which is capable to maintain the relationship among different version of ontology explicit. We show operational analysis of the proposed work for the better understanding about ontology versioning framework. Keywords Versioning, knowledge Unit, Annotation, Ontology 1. Introduction • Changes in the domain • Adaptations to different applications. Ontology is widely used for sharing the • Changes in the conceptualization or information. A classical ontology comprises understanding of the domain. classes, instances, axioms and properties. These • To correct errors properties can be data property (relate a class • Catering the ontology to a new with data value) and object property (relate two phenomenon classes with each other) [1]. In opposite to Ontology versioning implies that an classical ontology, a realistic ontology comes ontology has various variants. In fact, these into the scenario where every concept is stored variants frequently drive from modifications to as a knowledge unit by comprising classes, set an existing variant of the ontology and thus of defining properties (that define the concept build a derivation tree [3]. Klein et al. [4] uniquely or distinguish it with others), set of describe ontology versioning as a process that cancellable properties (that may or may not true manage the ontology changes and their effects for the concept), set of exceptions, UNK (used by maintaining and creating diverse variant of to complete the concept), instance and axioms the ontology. Ontology versioning maintains [2]. Ontology changed over the time according the synergy between different versions of the to the need of the application that generates ontology that creates at the same time. different version of the same ontology. Ontologies have a general tendency to have Ontologies undergo changes due to one or all of more changes the earlier they are in their the following reasons: lifecycle. Modularized ontologies generally ISIC’21: International Semantic Intelligence Conference, February change asynchronously, i.e., without changes in 25-27, 2021, New Delhi, India a module may begin waiting for the changes in archanamca92@gmail.com (A. Patel); jasarika@nitkkr.ac.in some another module to commit. There are two (S.Jain) 0000-0002-7505-7226 (A.Patel); 0000-0002-7432-8506 (S.Jain) categories of changes. One affecting the TBOX ©️ 2021 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). i.e., the ontology and the other affecting the CEUR WorkshopProceedings (CEUR-WS.org) ABOX i.e., the content. Table 1 lists some example of Ontology changes and some ontology change has a non-dynamic example of content changes. response, it may affect the use of these ontologies by higher level applications. Table 1 Klein et al. [4] describe the various Changes in Ontology requirements on an ontology versioning T-Box framework that are useful to create different 1. Changes in Hierarchy: Adding/removing a versions of internal ontologies: Identification (a class or property, Merging two classes or versioning framework should provide/identify properties, Splitting a class into two classes. the concept or relation in an unambiguous 2. Changes involving Classes: Renaming a manner), Change specification (versioning class, Changing label, comment or framework should be able to make the cardinality of a class, Changing or removing relationship explicitly from one version of the parent, Adding/removing a child, concept with other versions), Transparent Adding/removing a property to/from a class. evolution (versioning methodology on the web 3. Changes involving Properties: Renaming a should make clear which part of the data can property, Changing the domain/range/sub- still be valid interpreted), Task awareness (a property, reference/label/comment of a framework should exhibit the behavior or task property. that helps in providing the transformations 4. Other change types: Property between different versions), Tackle to untraced characteristics, Equality or inequality, changes (a versioning framework should able to Restricted cardinality, Union or intersection. determine whether two versions of an ontology A-Box are compatible or not). The key problems of 1. Changes involving instances: Renaming ontology versioning are (1) how to check (track an instance, Changing annotation of the and detect) ontology changes, (2) how to instances, Adding or removing instances, distribute (release) new versions of ontologies, Adding/removing properties and their (3) how to merge different versions of an values. ontology [5]. 2. Changes involving properties: Renaming a In order to reduce these problems, the property, Changing the domain/range/sub- versioning information is encoded at meta level property, reference/label/comment of a and term level but still there is a requirement to property develop sophisticated versioning mechanisms to incorporate ontology changes. In this paper, When knowledge managers locate the changes we focus on “how to encode versioning between different versions of an ontology, we information in an ontology when ontological call it comparing the two ontologies as opposed concept is stored as a knowledge unit”. The to versioning the two ontologies. Why remaining paper is presented as given below: Versioning Systems are required? section 2 shows the literature of the versioning • Implementing FAIR vocabularies: It is information, section 3 describes the ontology one of the best practices for versioning framework for the realistic implementing FAIR vocabularies and ontology, section 4 resembles the operational ontologies on the web. analysis for the storage of versioning • Backward Compatibility: The tools information along with the comparison with that work with older versions of the existing work and last section concludes the ontologies are functioning in new proposed work. versions too. • Resolving semantically (than 2. Literature syntactically): If conceptual relations between different versions are Ontology versioning is required in order to constructed, it becomes possible to re- handle ontology changes. The challenges and interpret the data and knowledge under research opportunities of ontology versioning different ontology versions. are: • Require changes in application logic: • Two ontologies with different text Applications need to update their logic serializations may be conceptually the to reference the new ontology. If the same. The difference in text representations may be due to different storage syntax or appropriate detail of each entity. Deprecation is due to different order of definitions. a feature which is used to deprecate the term • Distributed authoring and management (to (deprecating a term means that term will not use identify versions of an ontology in in new document). We can deprecate classes distributed environments). and properties according to the needs. • Application-level dependencies need to be For example, Biological Collections considered. Ontology (BCO) [8] has store owl:versionIRI, • To specify change logs between ontology dc:contributor, terms:license at the meta level versions explicitly. and annotation properties namely hasVersion, • Identify additional ontology changes Issued, Modified, Replaces, Status has been The first approach for ontology versioning is created in order to stored term level versioning proposed by Klein and Stojanovic [6] but the information. The versioning information of problem was unavailability of the standard class Taxon has hasVersion: ontology versioning system like CVS that use http://rs.tdwg.org/dwc/terms/history/#Taxon- in software development field. The versioning 2014-10-23, Replaces: information has been encoded at the meta level http://rs.tdwg.org/dwc/terms/Taxon-2009-09- and term level. The meta level versioning 21, Status: recommended, Issued: 2008-11-19, information describes the meta detail of the Modified: 2014-10-23. Deprecated property is ontology and term level versioning information used to deprecate the class BCO-0000061. describes the detail of every terms that are Different portals stored the versioning stored in ontology. The versioning information information of the terminologies or ontologies is stored by using different tags that available by using different tag and annotation properties. under the different namespace like /terms/, The meta level versioning information is /elements/1.1/ etc [7]. The following tags are encoded under the tag that can used at the meta level and term level for the be easily seen if an ontology file is opened into storage of versioning information: notepad. The term level versioning information Meta Level Tags: Ontology uses IRI to can be easily seen if you open the ontology in identify the ontology and owl:versionIRI is the protege tool or any other tool. In the used to identify the specify version of the protege, after clicking the concept, all ontology. dc:contributor is used to define the information of that concept is shown under the responsibility of the entity that make annotation properties. The most widely used contribution to the resources. terms:license ontology portals are Bio Portal, Agro Portal, offers official permission to work with the OBO lib, AberOWL repository and ontology resource. dc:description describes the lookup services. resources. dc:title assigns the name to the • Ontology Versioning in Bio Portal [9]: resources. dc:creator describes the entity which Bioportal uses the indexing mechanism in is responsible for making the resources. order to support ontology versioning. A dc:publisher offers the available resources. stable ontology identifier is used to index dcterms:modified updates the date according to the ontology and each versions of an the status of the resource. dc:language describes ontology is indexed with version identifier. the language of the given resources. The version identifier changes from one oboInOwl:date tells the date which is version to another when new version of an associated with the event. dcterms:issued ontology is derived. The web services use describes the issuance date of the resources. the ontology and its versions by ontology dcterms:bibliographicCitation provides identifier and version identifier bibliographic reference of the resource. respectively. Term Level Tags: The annotation property • Ontology Versioning in OBO lib: The URI is used for the storage of the term level is used in the OWL language to identify all versioning information. hasVersion, Issued, the entities of an ontology like classes, Modified, Replaces, Status, date, created_by, instances and ontology itself. The versionInfo, creator, contributor, terms, author, permanent URL (called PURL) of an priorVersion, backwardCompatibleWith and ontology with standard base prefix [10] are incompatibleWith etc can be created under the used in OBO repository of ontologies in annotation property in order to store the order to check if new versions of an ontology are updated and the tools are still functioning that support older versions of realistic description of the real-world entities. A an ontology. OBO uses versioning system node or a unit of knowledge (UoK) to represent where each version of an ontology has a a knowledge packet takes the form of the unique identifier either in form of metadata following tuple [15]: tags and date or numbering system [11]. • Ontology Versioning in Agro Portal [12]: 𝐃 [𝐓𝐄, 𝐀𝐄, 𝐕𝐄, 𝐏𝐄](𝝎) =< 𝑫𝑭(𝜸), 𝐂𝐅, 𝐂(𝜹), 𝐆, 𝐒, 𝐈 > (1) AgroPortal supports ontology versioning by utilizing the concept of ‘submission’. A ‘submission’ object is attached with an TE, AE, VE, PE are the textual encryption, ontology when the same ontology has been audio encryption, video encryption and uploaded in the portal. Whenever an pictorial encryption of the ontology is uploaded or pulled from its class/concept/decision D respectively. DF, CF original location then every time a new and C are the distinctive features, cancellable submission object is created. features and exceptions of the class/concept/decision D respectively. G and S • AberOWL Repository: It is a framework are the general and specific that provides ontology-oriented access of class/concept/decision. The parameters the biological data [13]. The framework γ, δ, and ω represents 0-degree, 1-degree and 2- contains repository of the ontologies that degree of the strength of the are related to the biological data, set of web class/concept/decision. I represents instances of services, various frontends and provide the class/concept/decision D that takes reasoning over the stored ontologies. The following form [16]: versioning information is encoded at the meta and term level by using various 𝐈 [𝐓𝐄, 𝐀𝐄, 𝐕𝐄, 𝐏𝐄] = < 𝑫𝑭, 𝐂𝐅, 𝐒𝐃, 𝐓𝐃 > (2) ontology tags. • Ontology Lookup Services (OLS): It SD and TD are the spatial and temporal provides single point access to the latest details of the instance I respectively. The below version of the biomedical ontologies from mentioned RDF/XML codes show the storage the repository [14]. OLS shows ontology of distinctive feature (distinctive feature history in order to describes the changes ‘nature’ of the class ‘Emergency’ with value that occurs in different version of an ‘sudden’), cancellable feature (cancellable ontology by calculating various parameters feature ‘hasWarning’ of concept ‘Emergency’ like add classes, add level, add synonyms, with a default value ‘no’) and instance (spatial add definition, delete definition etc. and temporal information of an instance Available portals stored the classical ‘Agartala_2008’ of the concept ‘Emergency’) in ontologies and encode the versioning the realistic ontology. All the distinctive and information inside itself. The main problem for cancellable features are encoded by creating the storage of the versioning information inside ‘DistinctiveFeatures’ and the classical ontology is how to deprecate the ‘CancellableFeatures’ properties; the SD and term/resources, how to use same syntax for TD information about the instances are stored creation of the versioning properties under the by creating ‘SpatialInfo’ and ‘TemporalInfo’ annotation. The process of storing the properties under the annotation properties. versioning information inside the realistic The versioning framework for the realistic ontology is not cover yet. Here our focus is to ontology is presented in figure 1. In the realistic present the versioning framework for the ontology, we need to store the versioning realistic ontology where every concept is information about the classes and properties represented as a whole. It is a first attempt to (distinctive and cancellable features) but do not show the encoding of the versioning need to store this information for the instances information inside realistic ontology. because all the instances are already stored with TD and SD in realistic ontology. TD and SD 3. Ontology Versioning Framework show the temporal details (time and date) and spatial detail (space of the instance) of the The realistic ontology in accordance with the Corresponding instances. In case, when we present subject matter represents rule, want to store more information about the exception, and hierarchy of concepts to offer a instances like creator, contributor, saved-by and many more then we follow the same process as Box. The knowledge about the classes and describes in section 4 for the classes. All the relations refer to the terminological knowledge knowledge about the instances refer to the and subject to the T-Box. They both together assertional knowledge and subject to the A- form the knowledge base. Figure 1: Versioning Framework for the Realistic Ontology 4. Operational Analysis C. Storage of Versioning Information for the Instances: All the instances are already The entities of an ontology are subject to the stored with spatial and temporal details in change and these changes occur at the meta the realistic ontology. There no need to level and term level (within the ontology). The store this information again. But for the meta level change updates the meta information storage of the rest of the versioning of an ontology like versionIRI, contributor, information like creator, contributors, license and etc. The term level change includes status etc, we use annotation property. The classes, properties or features and instances. below mentioned RDF/XML code shows These changes provide different version of the the versioning information namely same ontology. This section shows, how to add ‘Contributors’, ‘Creator’, and ‘Status’ term level (classes, properties and instances) about an instance ‘Agartala_2008’ of the versioning information in the realistic ontology. class ‘Emergency’. Figure 2 (c) shows the The storage of meta level versioning information inside the realistic ontology is screenshot of the protégé tool for the similar to the classical ontology. storage of versioning information about the instance ‘Agartala_2008’ of the class A. Storage of Versioning Information for ‘Emergency’. the Classes: We use annotation properties By the above-described way, we incorporate all for the storage of versioning information the changes inside an ontology that create about the classes as similar to the classical different version of an ontology. Now, every ontology. The below mentioned RDF/XML concept in the realistic ontology contains all the information about the entity that helps to code shows the versioning information understand the different version of an ontology. namely ‘Contributors’, ‘Creator’, There is no need to store the spatial and ‘DateTime’ and ‘Status’ about the class temporal information about the instances as ‘Emergency’. The screenshot attached as they already contained in the information while figure 2 (a) shows the protégé tool for the entering the systems. storage of versioning information about the class ‘Emergency’. B. Storage of Versioning Information for the Properties: The distinctive and cancellable features (properties) of the classes are stored by creating properties ‘DistinctiveFeatures’ and ‘CancellableFeatures’ under annotation property. We annotate all the (b) (a) ‘DistinctiveFeatures’ and ‘CancellableFeatures’ properties for the storage of versioning information. The below mentioned RDF/XML code shows the versioning information namely ‘Contributors’, ‘Creator’, ‘DateTime’ and ‘Status’ about the distinctive feature ‘nature’ that value is ‘sudden’ for the class ‘Emergency’. Figure 2(b) shows the (c) screenshot of the protégé tool for the Figure 2: Screenshot of the Protégé Tool for storage of versioning information about the the Storage of Versioning Information (a) Class distinctive feature ‘nature’ that value is ‘Emergency’ (b) Distinctive Feature ‘nature’ ‘sudden’ for the class ‘Emergency’. (c) Instance ‘Agartala_2008’ 5. Conclusion inside a realistic and classical ontology. Ontology versioning is a mechanism to store References and identify different versions of the same ontology. It can be achieved when user has [1] D. Kumar, A. Kumar, M. Singh, A. Patel, complete information about the entities used in S. Jain, An online dictionary and ontology. Ontology versioning information is thesaurus. Journal of Artificial Intelligence encoded at the meta and term level by using Research & Advances, (2019), 6(1), 32-38. different tags. The process to store versioning [2] S. Jain, A. Patel, Smart Ontology-Based information inside the classical ontology is Event Identification. In 2019 IEEE 13th shown by various ontology portals/repositories. International Symposium on Embedded But how to store versioning information in the Multicore/Many-core Systems-on-Chip realistic ontology is not being covered yet. In (MCSoC) (2019), pp. 135-142), IEEE. this paper, we present the versioning [3] M. C. Klein, D. Fensel, Ontology framework for the realistic ontology that assists versioning on the Semantic Web. users to easily analyze the different version of a In SWWS (2001), pp. 75-91. realistic ontology. We have shown RDF/XML [4] M. Klein, A. Kiryakov, D. Ognyanoff, D. code and screenshot of the protégé tool for the Fensel, Finding and specifying relations demonstration of the proposed versioning between ontology versions. In Proceedings framework. In future, we will work to deprecate of the ECAI-02 (2002), Workshop on the entities and to reduce the problem of storing Ontologies and Semantic Interoperability. Versioning information related with the entity Lyon , pp. 442-456. [5] M. Klein, D. Fensel, A. Kiryakov, D. [10] Version Control, Ognyanov, Ontology versioning and URL: https://en.wikipedia.org/wiki/Versi change detection on the web. on_control In International Conference on Knowledge [11] OBO Foundry, URL: Engineering and Knowledge Management http://www.obofoundry.org/principles/che (2002), pp. 197-212. Springer, Berlin, cks/fp_004 Heidelberg. [12] C. Jonquet, A. Toulet, E. Arnaud, S. [6] M. C. A. Klein, Change management for Aubin, E. D. Yeumo, V. Emonet, P. distributed ontologies, (2004). Larmande, AgroPortal: A vocabulary and [7] DCMI Metadata Terms, URL: ontology repository for agronomy. https://www.dublincore.org/specifications/ Computers and Electronics in Agriculture dublin-core/dcmi- (2018), 144, 126-143 terms/#http://purl.org/dc/terms/bibliograph [13] Aber OWL, URL: http://aber- icCitation owl.net/about/ [8] R. L. Walls, J. Deck, R. Guralnick, S. [14] OLS Ontology Search URL: Baskauf, R. Beaman, S. Blum, M. A. https://www.ebi.ac.uk/ols/ontologies Gandolfo, Semantics in support of [15] A. Patel, S. Jain, A Novel Approach to biodiversity knowledge discovery: an Discover Ontology Alignment, Recent introduction to the biological collections Advances in Computer Science and ontology and related ontologies Communications (2020,) 13: 1, Doi: (2014), PloS one, 9(3), e89606. https://doi.org/10.2174/266625581366619 [9] N. F. Noy, N. H. Shah, P. L. Whetze, B. 1204143256 Dai, M. Dorf, N. Griffith, M. A. Musen, [16] A. Patel, S. Jain, S. K. Shandilya, Data BioPortal: ontologies and integrated data of Semntic Web as Unit of resources at the click of a mouse. Nucleic Knowledge. Journal of Web Engineering acids research, (2009), W170-W173. (2018), 17(8), 647-674.