DSont: DSpace to ontology transformation

Abstract

Semantic web facilitates the effective sharing and reuse of existing information. Institutional repositories (IRs) are built to organize and manage the intellectual output of an institute. They generally use relational databases for maintaining metadata of digital documents. The focus of this research is to share the information of an existing IR with other information systems for discovering common interests. To process the data in semantic context, a relational database needs to be transformed into an ontology. The existing relation to ontology transformation systems produces odd results if they are applied on an IR database because its schema is meta-schema. The proposed system first creates an intermediate database, having a normalized schema for the data model of an institute preserved in an IR database and then transforms it into an ontology. Finally semantic correspondence is established between entities of source and target ontologies in order to integrate them. The system has been implemented and evaluated for its correct and lossless transformation. The results demonstrate that the transformation is correct and the information is preserved.

Keywords

Database information sharing institutional repository metadata ontology Semantic Web

1. Introduction

Internet technologies have enabled academics to connect and collaborate by sharing their research online. An ontology can facilitate the effective sharing and reuse of existing information and can create an integrated view of multidisciplinary information [1 –5]. It represents a data source at a higher level of abstraction and manifests the semantics of a source [6]. It provides self-describing data which is readable by machines and performs reasoning to categorize and find associations. VIVO¹ is an open source ontology (i.e. Semantic Web application) that has been developed to enable discovery of research and scholarship across disciplines [4, 5].

Institutional repositories (IRs) are often built to organize and manage the intellectual output of an institute to enhance scholarly communication. They encourage collaboration within and between disciplines and groups to help faculty, researchers and students discover common interests and make connections [7]. Most existing IRs, such as DSpace,² EPrints,³ Invenio⁴ and Archimede,⁵ are commonly used relational database schema for maintaining metadata that provide detailed description about digital documents. We have adopted for this research DSpace, an open source IR software, developed by MIT and HP Labs, USA [7 –9]. A noteworthy feature of all IRs, particularly DSpace, is their flexible data models that can be customized to arrange the digital documents in a repository according to the organizational structure of an institute [7, 10]. An IR database handles the many different data models that institutes have without the need for changes to its internal schema. The data model of an IR is not directly converted into an IR database schema, but it is stored in the IR database. In other words, there is no one-to-one correspondence between the entities of an IR data model and the relations of the IR database. A database schema is known as normalized (i.e. relational normal form) when there is one-to-one correspondence between the entities of a data model and the relations of a database. The schema of an IR database is a meta-schema, that is, a schema to describe another schema. An IR database schema is not a normalized schema with respect to the data model of an institute.

The aim of this research is to share the information of an existing IR with other information systems within the institution or outside to help its community for discovering common interests and making connections. In order to enable users from the outside world to discover and explore the full range of research and scholarship available in an institute, we need to transform an IR database into an ontology. The ontology helps in integrating its data with a target ontology such as VIVO for the sharing and reuse of information for knowledge discovery. A substantial amount of research has already been carried out in transforming a relational database to an ontology [11 –18]. However, the existing relation to ontology transformation systems produce odd results if they are applied on a DSpace database because its schema is a meta-schema, not a normalized schema. DSpace database relations cannot be mapped to ontology classes because a class has to be created for a data model’s entity, which is preserved in a database relation. Therefore, it is necessary to extract the data model from a DSpace database prior to transforming it into an ontology. This makes the transformation novel from the typical relational to ontology transformation. Moreover, some of the existing systems do not properly create a parent–child hierarchy (i.e. generalization and specialization) between classes of an ontology and some others do not appropriately handle multivalued attributes of database relations in transformation and lose data semantics. In addition, the ontology created from an IR database needs to be aligned with the target ontology, for example, VIVO, in order to populate its data into the target ontology. It can be achieved by identifying or establishing semantic correspondence between the entities (i.e. classes and properties) of both ontologies.

Our proposed system DSont extracts data (i.e. metadata of digital contents) from an IR database to identify the data model of an IR and builds an intermediate relational database that has a normalized schema with respect to the identified data model. Then additional relevant data are extracted from the IR database to populate this intermediate database. Once we get a relational database with a normalized schema, then a relational to ontology transformation technique can be applied on this database to transform it to an ontology. We extended the basic relation to ontology transformation rules to make them capable of handling multivalued attributes of a relation and creating a parent–child hierarchy in an ontology. Once we generate an ontology, then the instances from the generated ontology can be aligned and integrated with data or instances expressed in the target ontology. In order to perform that, the classes from both source and target ontologies are extracted and simple mappings between these classes are semi-automatically generated by a user. Then the individuals (i.e. instances) of these mapped classes are matched and proper Universal Resource Identifiers (URIs) are given to each individual. These individuals are linked with their respective VIVO classes. Finally, a resource description framework (RDF), having VIVO individuals, is generated and loaded into VIVO.

The distinguishing features of the proposed system are: (a) identifying the data model of an institute; (b) extracting metadata of a repository; (c) building a proper parent–child hierarchy between classes of ontology to preserve the data model hierarchy; (d) generating mappings between ontologies; and (e) translating data or instances from a source ontology into corresponding data or instances expressed in the target ontology. The evaluation criteria of the proposed system are: (a) preservation of information capacity; and (b) transformation accuracy. The former is important to find information loss (if any) as a result of transformation and the latter is significant to find the quality of the built ontology. A correct and lossless transformation ensures that all data in a source model is represented in the target model. Three datasets were used for the evaluation of our system. The evaluation demonstrates that the proposed system produced positive results. The rest of this paper is organized as follows. Section 2 briefly introduces VIVO and DSpace, and describes an IR data model as an example. Section 3 describes the related work. Section 4 presents the proposed system. Section 5 illustrates result evaluation and comparison. Finally Section 6 concludes the paper.

2. Case study – Dspace to VIVO

In this section, we introduce VIVO and DSpace and justify their selection for this research. Moreover we provide an example scenario that will be used in explaining the steps of the proposed system DSont throughout this paper. The VIVO project started at Cornell University and was further developed by a National Institutes of Health⁶-funded consortium. It is now being established as an open-source project with community participation from around the world. It produces ontology so that information can be exchanged, aggregated and searched by others on the web through standard protocols. It is populated with detailed profiles of faculty and researchers including information such as publications, teaching, service and professional affiliations. It enables collaboration by sharing information about researchers and their activities, and clusters it into different categories, for example, activities, people, organization, events, publications for effective searching and retrieval [4, 5, 19].

DSpace is the most widely used open source IR software worldwide, as demonstrated by OpenDOAR⁷ statistics. It uses a relational database to preserve the metadata of digital contents, such as, author, publication data, document type (i.e. thesis, article and report) and publisher [10]. A promising aspect of DSpace is its flexible data models that can be customized to arrange the digital documents in a repository according to the organizational structure of an institute [7, 10]. The data model is divided into communities, which can be further divided into subcommunities reflecting the typical organizational structure of an institute. For example, communities and subcommunities are defined as schools, departments, laboratories and centres of an institute. Communities contain collections, which are groupings of related content. Each collection is composed of items, which are the basic archival elements of a repository. DSpace defines a comprehensive database schema for its flexible data model, as shown in Figure 1. A portion of its database schema in the relational model is shown in Table 1.

Figure 1.

Major relations of DSpace database.

Table 1.

A relevant portion of DSpace database schema.

Relation	Foreign key
item (item_id, submitter_id, in_archive, withdrawn, owning_collection)	owning_collection referring to collection_id in collection
collection (collection_id, name, short_description, submitter)	Nil
community2collection (id, community_id, collection_id)	community_id referring to community_id in community, collection_id referring to collection_id in collection
community (community_id, name, short_description)	Nil
community2community (id, parent_comm_id, child_comm_id)	parent_comm_id and child_comm_id referring to community_id in community
metadatafieldregistry (metadata_field_id, element, qualifier, scope_note)	Nil
metadatavalue (metadata_value_id, item_id, metadata_field_id, text_value)	item_id referring to item_id in item, metadata_field_id referring to metadata_field_id metadatafieldregistry

A DSpace data model of an institute – the School of Electrical Engineering and Computer Science (SEECS), National University of Sciences and Technology (NUST), Pakistan – is shown in Figure 2. It is considered as an example to demonstrate the proposed system throughout this paper. The data model shows entities that contains one main community (e.g. SEECS), eight subcommunities (e.g. Department of Computing) and 10 collections (e.g. UG thesis). Items are instances of collection entity, which is not shown in the figure. The arrow direction in the figure depicts specialization (i.e. child entity).

Figure 2.

DSpace data model of an institute.

3. Related work

The focus of this research involves the task of transforming an IR’s metadata into an ontology. An IR uses a relational database to store the metadata; however, its database schema is meta-schema, so it first needs to identify the schema of an IR data model and then transform it into an ontology. Hence, we divide the related work into three parts: (a) extraction of metadata from IRs; (b) transformation of metadata into an ontology; and (c) ontology alignment and data translation.

3.1. Metadata extraction

Various techniques exist to extract metadata from deep web, static web and legacy databases using reverse engineering techniques. The techniques proposed in the literature [18, 20] build a conceptual model (i.e. extended entity-relationship diagram) from database tables. The techniques are suitable for data sources that have little description about the fields in their tables and no description for keys. Maatuk et al. [21] present an approach to semantic enrichment for relational DataBase Migration. In this technique, necessary data semantics about a given relational database (RDB) are extracted and enhanced to produce relational schema representations. The relational schema representation constructs are then classified to develop a canonical data model (CDM), which provides a description of the existing RDB’s implicit and explicit semantics. The generated CDM is a sound source of semantics and is a well-organized data model, which facilitates an integrated approach to database migration. Gherabi et al. [22] also proposed a similar solution for migrating relational database into web semantics. It takes an existing RDB as an input, and extracts its metadata representation (MTRDB). Then a CDM is generated based on this extracted MTRDB. Finally, the structure of the classification scheme in the CDM model is converted into an OWL ontology.

Nagy et al. [23] present a method for extraction of data from tables. They transform the tables into a relational database that is accessible by both SQL and SPARQL for relational tables and RDF triple stores, respectively. They primarily focus on large statistical information sites. These sites are generated from databases without having direct access to the back-end databases. Kappel et al. [24] proposed a process for lifting meta-models into ontologies for the purpose of integrating modelling languages semantically. In this way, the concepts hidden by these modelling languages are represented explicitly by transforming a meta-model into an ontology.

3.2. Relation to ontology transformation

Most of the existing transformation systems [11, 14, 15, 18, 25, 26] use the basic transformation rules, that is: (a) every relation maps to an RDF schema (RDFS) class; (b) every tuple of a relation maps to an RDF node; (c) every attribute of a relation maps to an RDF property; and (d) for every tuple, the value of each attribute maps to a value of the property for the node corresponding to the tuple.

Relational.OWL [16] is the most popular and dominant work on the generation of a database schema ontology. However, it causes a lack of separation among classes, properties and individuals. Relational.OWL is also used in other tools and approaches, for example, ROSEX [26] and DataMaster [17]. The novelty of DataMaster [17] is to offer two alternative modelling versions of Relational.OWL that manage to stay within the syntactic bounds of OWL DL by providing separation among classes, properties and individuals. D2RQ [27] is one of the most prominent tools that generates domain-specific RDFS ontology. It exports the contents of a relational database to an RDF graph. The mappings is specified in a custom mapping language and a user can also modify the generated mapping. The engine that uses D2RQ mappings to translate requests from external applications to SQL queries on the relational database is called the D2R Server [13].

3.3. Ontology data translation

COMA++ [28] is a tool for matching schema to determine similarities between them. It uses different characteristics of a schema for identifying these similarities. These characteristics may include the names of the schema elements and their data types, structural information, etc. Instance-based matching has been proposed [29] for COMA++. It supports different sources such as relational schema, XML and ontologies for importing instance data. Different parsers have been used for parsing a schema and the instance data from different sources. The same generic data representation is used for representing different instance data. Two instance-based matchers are used in this approach. These matchers are content- and constraint-based matchers that use several linguistic approaches and constraints. They generate similarity matrices that are combined for deriving a mapping between schema elements. Araújo et al. [30] proposed a tool, SERIMI,⁸ which interlinks the datasets published in the Linked Data Cloud. It focuses on the instance matching problem over RDF data and matches instances between a source and a target datasets without prior knowledge of the data, domain or schema of these datasets. This solution is composed of two phases: the selection phase and the disambiguation phase. It uses existing string-matching algorithms for solving the selection phase. A new function of similarity is used during the disambiguation phase, which operates even without having any direct ontology alignment between the source and target datasets.

An ontology-based information extraction system, BOEMIE (Bootstrapping Ontology Evolution with Multimedia Information Extraction),⁹ has been developed for extracting objects automatically from various media types such as images, video, audio, text, etc. [31]. BOEMIE also proposes ontology population methodology. Castano et al. [32] developed an instance-matching component, HMatch(I) of the HMatch 2.0 ontology matching suite [33]. This component is developed in the framework of the BOEMIE project, which provides instance-level matching techniques for supporting ontology population tasks. It supports both syntactic and semantic approaches for instance matching. It also has the ability to identify featuring and non-featuring properties. It applies statistical techniques for learning information about featuring properties. These featuring properties highly contribute to the identification of individuals. Knoblock et al. [34] developed a web application, Karma,¹⁰ which allows users to integrate data from various sources. Data can be extracted from relational databases, XML files or CSV files and this data can be published in different formats, that is, CSV or RDF. Conditional Random fields [35] are used for learning semantic types and the relationships among the source’s schema elements are identified by using the Steiner tree algorithm. RDF generated by the Karma can be loaded into VIVO by creating proper URIs according to the VIVO ontology. The initial mappings are generated semi-automatically, which can be refined and modified by users.

3.4. Critical analysis

The existing metadata extraction techniques [18, 20 –24, 36] are domain and application oriented and apply reverse-engineering techniques for extracting data. They cannot be applied in different domains and applications because they have been specifically designed for their respective applications.

The existing relation to ontology transformation systems [11 –18] cannot produce accurate results if they are applied on an IR database because its schema is meta-schema. An IR database relation cannot be mapped to an RDFS class because an RDFS class has to be created for a data model entity that is a tuple of a relation. Therefore, it is necessary to extract the data model from the IR database prior to transforming it into an ontology. The existing transformation systems are capable to transform a normalized relational database; however, DataMaster [17] and D2R server [13] do not create a proper hierarchy of parent and child classes so they are not able to preserve the IR data model hierarchy. R2O [18], DM-2-OWL [11] and ROSEX [26] do not populate an ontology with instances from the database. Astrova [12], DB2OWL [15], DM-2-OWL [11], RDBToOnto [14], ROSEX [26], DataMaster [17] and D2R server [13] do not handle the multivalued attributes appropriately during transformation, which can cause loss of information in transformation.

Engmann and Maßmann [29] proposed a technique for instance matching that does not populate an ontology with new instances. Araújo et al. [30] proposed a tool that links instances without populating the ontology. However, Castano et al. [31] developed an instance-based matching component that is used for an ontology population, but this is a domain specific approach which cannot be applied in our case. The most related technique was proposed by Knoblock et al. [34], but it does not allow the extraction of data from ontologies. It uses relational databases, XML files and CSV files for data extraction. It requires user intervention for generating mappings, which makes it a more time-consuming and an error-prone task.

4. Proposed system: DSont

DSont has been designed for transforming DSpace into an ontology to publish it on the Semantic Web. It extracts the metadata from a DSpace database, creates a normalized intermediate database and transforms it into an ontology. Finally, instances from the generated ontology are transformed into corresponding data or instances expressed in the target ontology. DSont is divided into three main modules: (a) metadata extraction; (b) data transformation; and (c) alignment and translation. These modules are described in the following subsections and explained with examples. Each figure in an example is divided into two parts, the left side of a figure depicting the schema of a DSpace database and the right side representing corresponding extracted information. In these figures rectangles and ellipses represent relations and their attributes respectively. The values of their respective attributes are represented by arrays.

4.1. Metadata extraction

In this module, an IR data model and its data are obtained by extracting metadata from a DSpace database. This module further comprises three subcomponents as discussed below.

4.1.1. Identification of data model (IDM)

Since DSont generates an ontology for an institutional repository, it needs to identify its data model. The data model (DM) of an institutional repository is stored in a DSpace database. In this subcomponent, entities of the data model and its relationship are identified in order to build an intermediate database and subsequently an ontology’s classes. The entities of a data model $E (DM)$ are categorized into communities CM and collections CL; the communities are further categorized into main communities ${CM}_{m}$ and sub communities ${CM}_{s}$ . An entity $E_{i} \in E (DM)$ can be defined as $\forall E_{i} \in ({CM}_{m} \lor {CM}_{s} \lor CL)$ .

Definition 1. Main community

${CM}_{m}$ represents a set of main communities and its element is ${CM}_{m_{i}}$ , that is, ${CM}_{m_{i}} \in {CM}_{m}$ . $E_{i}$ is a ${CM}_{m_{i}}$ iff: (a) $E_{i}$ is a subsumer and (b) $E_{i}$ is not a subsumee. This means that the entity $E_{i}$ has no parent but it has child(ren).

In the example data model, shown in Figure 2, SEECS is a main community.

Definition 2. Subcommunity

${CM}_{s}$ represents a set of subcommunities and its element is ${CM}_{s_{i}}$ , that is, ${CM}_{s_{i}} \in {CM}_{s}$ . $E_{i}$ is a ${CM}_{s_{i}}$ iff: (a) $E_{i}$ is a subsumer; and (b) $E_{i}$ is also a subsumee. This means that the entity $E_{i}$ has both parent and child(ren).

In Figure 2, Dept. of Computing and Documents, Reports are examples of subcommunities.

Definition 3: collection

CL represents a set of collections and its element is ${CL}_{i}$ , that is, ${CL}_{i} \in CL$ . $E_{i}$ is a collection ${CL}_{i}$ iff: (a) $E_{i}$ is not a subsumer; (b) $E_{i}$ is a subsumee; and (c) $E_{i}$ is not an empty set, It means that the entity $E_{i}$ has a parent but it has no child(ren).

Moreover ${CL}_{i}$ is subsumed by either ${CM}_{s_{i}}$ or ${CM}_{m_{i}}$ and ${CL}_{i}$ is a set of items $I_{j}$ . In Figure 2, UG Thesis, Conference Proceedings and Journal Articles are examples of collections. $I_{j}$ is a basic archival element of a repository. Items are the instances of a collection ${CL}_{i}$ . For example, an article ‘Data Exchange’ is an item owned by the Journal Articles collection.

IDM algorithm

The process of IDM is shown in Figure 3. Entities of DM are identified by extracting identifiers (IDs) of an item $I_{j}$ and its corresponding owning collection ${CL}_{i}$ from item table of DSpace schema, shown in Table 1. A collection name is then extracted from the collection table. The identifier of the community, containing ${CL}_{i}$ , is extracted from the community2collection table and subsequently its name is extracted from the community table. This process of identifying communities is continued until the main community is identified. Similarly this hierarchy of entities are identified for all items maintained in the item table. In the end, a list of hierarchy of entities is produced.

Figure 3.

Flowchart of data model identification.

4.1.2. Building of schema

In building of schema (BS), the extracted data model (DM) is used for creating the schema of an intermediate database (IDB). The following steps are used for BS:

create a database relation $R_{{CM}_{m_{i}}}$ for an entity $E_{i} \in {CM}_{m}$ ;

create a child relation $R_{{CM}_{s_{i}}}$ of its respective parent relation $R_{{CM}_{m_{i}}}$ for an entity if $E_{i} \in {CM}_{s}$ ;

create a child relation $R_{{CM}_{s_{j}}}$ of $R_{{CM}_{s_{i}}}$ for an entity ${CM}_{s_{j}}$ if any parent ${CM}_{s_{i}}$ exists;

create a child relation $R_{{CL}_{i}}$ for an entity $E_{i} \in CL$ of its respective parent entity (i.e. community).

Attributes of the intermediate database relations are extracted from their respective tables of a DSpace database. Since a collection ${CL}_{i}$ relation contains a set of items $I$ , therefore Dublin code attributes atts of the relation $R_{{CL}_{i}}$ are extracted from metadata of the item I that is maintained in the metadatafieldregistry table of a DSpace database.

BS algorithm

The process of BS is shown in Figure 4. First of all, an item identifier is selected from the DSpace database table Items to obtain its main community. If a table exists in the IDB for the main community then its subcommunities are identified, otherwise the process is repeated for other main communities. The same process is repeated for subcommunities until a table is created for their respective collection. Attributes of IDB relations are then extracted from the metadatafieldregistry table of the DSpace database and the respective table is updated accordingly.

Figure 4.

Work flow of intermediate database schema building.

4.1.3. Population of intermediate database

In populating the intermediate database (PID), data is extracted from a DSpace database and populated in the intermediate database by using the following steps:

insert item identifiers in the extracted relations $R_{{CM}_{m}}$ and $R_{{CM}_{s}}$ ;

extract the values of the attributes atts of a relation $R_{{CL}_{i}}$ from the contents of the table metadatavalue of a DSpace database for each item;

create a weak primary relation $R_{{MV}_{i}}$ if an attribute is found complex,¹¹ as a child relation of $R_{{CM}_{m_{i}}}$ in the intermediate database. The PID component populates the new relation with appropriate extracted data;

create a weak secondary relation $R_{{CMV}_{i}}$ if an attribute is found to be multivalued attribute, as a child relation of $R_{{CM}_{i}}$ in the intermediate database. The PID component populates the new relation with appropriate extracted data.

PID algorithm

The work flow of PID process is shown in Figure 5. The first step is getting all items and their corresponding communities and collections from the identified data model. The tables of the intermediate database that were created for communities are searched and item identifiers are inserted. Then the table, created for the corresponding collection, is searched and metadata values of respective attributes are inserted in this table. These metadata values are extracted from the metadatavalue table of a DSpace database. Before inserting values, we check whether an attribute is multivalued or complex attribute. If it is found to contain such an attribute, then a new table is created. This process is repeated for all items.

Figure 5.

Work flow of intermediate database population.

After applying all three subcomponents in the first module of the system on the example data model shown in Figure 2, an intermediate database, having 23 relations (tables), is created as shown in Figure 6.

Figure 6.

Generated relational database of the DSpace structure.

4.2. Relation to ontology transformation

In this module, the intermediate database is transformed into an ontology using the basic transformation rules. Let R represent the relations where $R_{i} ε R$ , X represents the total attributes of the relation $R_{i}$ and Y represents the non-key attributes of the relation $R_{i}$ . The following rules are used for this transformation:

Rule 1: an OWL class $C_{i}$ is created for a relation $R_{i}$ , if one of the following conditions is satisfied: (a) $R_{i}$ does not contain any foreign key ${FK}_{i}$ ; and (b) the primary key of the relation does not contain a key of any other relation, such that ${PK}_{i} Π {FK}_{〉} = ϕ$ .

Rule 2: if two relations $R_{i}$ and $R_{j}$ have their primary keys linked with a foreign key constraint $({PK}_{i} = {FK}_{i})$ , they are mapped to two OWL classes $C_{i}$ and $C_{j}$ , respectively, the one being a super-class of the other. rdfs:subClassOf is added to the respective class.

Rule 3: OWL $C_{i}$ is created for a relation $R_{i}$ and rdfs:subClassOf is added, if it fulfills the following criteria: (a) ${FK}_{i} \subset {PK}_{i}$ means that $R_{i}$ has a composite primary key that contains keys of other relations; and (b) $\exists Y ε X - {PK}_{i}$ means tha $R_{i}$ has non-key attributes.

Rule 4: OWL class is not created for $R_{i}$ , if it fulfills the following criteria: (a) ${FK}_{i} \subset {PK}_{i}$ means that $R_{i}$ has a composite primary key which contains keys of other relations; and (b) $| X - {PK}_{i} | = 0$ means that $R_{i}$ does not have any non-key attribute. A DataTypeProperty is created for the primary key attribute that is not a foreign key and added to the class that has been created for its parent relation. The attribute that is both a primary key and a foreign key is discarded because it has already been converted to the functional Datatype property in the parent relation.

Rule 5: for each non-key attribute att of a relation $R_{i}$ , an OWL DatatypeProperty $P_{i}$ is created.

Rule 6: for each primary key attribute ${PK}_{i}$ of a relation $R_{i}$ , a functional DatatypeProperty $P_{i}$ is created with minCardinality restriction of 1 as the primary key is UNIQUE and NOT NULL.

Rule 7: for each foreign key ${FK}_{i}$ of a relation $R_{i}$ , an ObjectProperty $P_{i}$ is created. Let a relation $R_{i}$ (i.e. child relation) refer to a relation $R_{j}$ (i.e. parent relation); their corresponding classes are $C_{i}$ and $C_{j}$ , respectively. The domain and range of the ObjectProperty are specified as Domain of $P_{i}$ = $C_{i}$ and Range of $P_{i}$ = $C_{j}$ . A restriction of allValuesFrom is applied to the property so that all values of the foreign key should come from the primary key of the parent relation.

Rule 8: for every tuple $R_{i} [t_{i}]$ , the value of an attribute att maps to a value of the property $P_{i}$ .

Algorithm

The main work flow of this transformation is shown in Figure 7. The first step is to obtain the tables of the intermediate database and create an appropriate ontology class for each table. Then, attributes of the tables are extracted and checked one by one to determine whether it is a primary key or a foreign key or non-key attribute. Each type of attribute is handled according to the defined rules. Instances of the ontology classes are created for all attribute values. Finally, the ontology is generated.

Figure 7.

Work flow of relation to ontology transformation.

Example

The ontology created for the given DSpace data model is shown in Figure 8. In this ontology, the OWL class seecs_5 was created for the main community SEECS, and subclasses were created for every subcommunity, collection and multivalued attribute, such as dept_of_computing_7, conference_proceedings_12 and author_seecs respectively. For example, a functional datatype property is created for the primary key (i.e. id) of the intermediate database relation seecs_5. Similarly the functional object property with cardinality restriction 1 is created for the foreign key (i.e. id) that is also defined as a primary key in table dept_of_computing_7. Since the primary key is linked with a foreign key constraint (i.e. PK=FK), so dept_of_computing_7 has been made as a subclass of seecs_5.

Figure 8.

Graphical representation of the generated ontology.

4.3. Ontology alignment and data translation

The data of an ontology, created by applying the above two modules, cannot be imported directly into any target ontology without translation. In this module, two ontologies are taken as inputs and a source ontology is aligned with the target ontology. Then data is translated from the source to the target ontology.

Definition 4: Resource mappings (RM)

Given two ontologies O1 (i.e. source ontology) and O2 (i.e. target ontology), C1, C2 are sets of concepts of O1 and O2, respectively, such that $C 1_{i} ε C 1$ and $C 2_{j} ε C 2$ . RM is an alignment A between the concepts of these two ontologies. A is a pair of $(C 1_{i}, C 2_{j})$ which means that $C 1_{i} \equiv C 2_{j}$ .

Definition 5: Instance matching (IM)

IM is a triple $(I 1_{k}, I 2_{l}, R)$ , where $I 1_{k} ε I 1$ and I1 are the instances of $C 1_{i}$ , $I 2_{l} ε I 2$ and I2 are the instances of $C 2_{j}$ and R is a relation between instances $I 1_{k}$ and $I 2_{l}$ . R is taken from the set {≡, ⊥} for equivalence and disjointness respectively. IM gives $I 1_{k}$ the same URI of $I 2_{l}$ , if $(I 1_{k}, I 2_{l}, \equiv)$ , otherwise, it creates a new instance $I 1_{k}$ of $C 2_{j}$ if $(I 1_{k}, I 2_{l}, ⊥)$ and links it with the existing data.

Algorithm

Figure 9 depicts the work-flow of this module. First of all classes from both ontologies are extracted. Next, a user selects appropriate classes semi-automatically and the system generates alignment between the concepts of the generated ontology O1 and the VIVO ontology O2. Second, the system compares the instances I1 of $C 1_{i}$ with the existing instances I2 of $C 2_{j}$ . If $I 1_{k}$ matches $I 2_{l}$ , this means that these two instances are equivalent. Therefore, it creates the triple $(I 1_{k}, I 2_{l}, \equiv)$ which shows that $I 1_{k} \equiv I 2_{l}$ . Then $I 1_{k}$ is given the URI of the $I 2_{l}$ , which identifies the two as the same instance. If $I 1_{k}$ does not match with any instance of $I 2_{l}$ , this means that these two instances are disjoint. Therefore, it creates the triple $(I 1_{k}, I 2_{l}, ⊥)$ , which shows that $I 1_{k} ⊥ I 2_{l}$ . The system gives a proper VIVO URI to $I 1_{k}$ .

Figure 9.

Work flow of ontology alignment and data translation.

URIs are arbitrarily generated by the system according to VIVO Namespaces. The system compares these URIs with the URIs already in VIVO and ensures that the URIs are unique. Finally the system links the new data with the existing data in VIVO. The complete class hierarchy is maintained by identifying and linking super and subclasses. At the end of this module, the system creates RDF code that contains individuals in VIVO format. After this step, all data is annotated with VIVO URIs and is ready to import into VIVO.

5. Evaluation and results

Transformation systems are mostly evaluated for preservation of information capacity and their correctness [18, 37]. Therefore the evaluation criteria of the proposed system are: (a) preservation of information capacity; and (b) transformation accuracy. The former is important to find information loss (if any) as a result of transformation and the latter is significant to find the quality of the generated ontology. A correct and lossless transformation ensures that all data in a source model is represented in the target model. The system evaluation was divided into two main parts in each criterion: (a) relation to ontology transformation; and (b) ontology data translation. We have implemented the transformation system (i.e. the algorithms mentioned in previous section) in Java and generated an OWL ontology using Jena-2.6.4 Ontology API for the DSpace data model.

For the evaluation of our system, we have randomly selected the following three datasets, where the first one is complex, the second is moderate and the last one is simple in order to evaluate the proposed system in different scenario. The specifications of these datasets are shown in Table 2. (a) Dataset 1 was harvested from Massachusetts Institute of Technology (MIT) DSpace. Eighteen collections were selected for data harvesting. Three collections are empty as they do not have any item. A total of 2242 items were harvested from 15 collections. This dataset contains three main communities and 10 subcommunities. These items contain 11 non-multivalued, five multivalued and three complex metadata fields, and these contain 37,032 metadata values. (b) Dataset 2 contains the DSpace database of an institute: theSEECS, NUST, Pakistan. This dataset contains 1 main community and 14 subcommunities in which five subcommunities contain empty collections. There are in total 12 collections in which five collections are empty and another seven collections contain 533 items. These items contain 12 non-multivalued, two multivalued and one complex metadata fields, and these contain 10,132 metadata values. (c) Similarly Dataset 3 contains a self-designed DSpace database. This dataset contains one main community and eight subcommunities. There are 10 collections which contain 100 items. These items contain nine non-multivalued, three multivalued and one complex metadata fields, and these contain 1679 metadata values.

Table 2.

Dataset specifications of DSpace data models used for evaluation.

	Communities			Collections		Items	Metadata fields			Metadata values
	Main	Sub (total)	Sub (empty)	Total	Empty		Non-multivalued	Multivalued	Complex
Dataset 1	3	10	0	18	3	2242	11	5	3	37,032
Dataset 2	1	14	5	12	5	533	12	2	1	10,132
Dataset 3	1	8	0	10	0	100	9	3	1	1679

5.1. Information preservation

This criterion finds out whether the source model (i.e. relational database) is completely transformed into the target model (i.e. ontology). In this evaluation, ontology classes, properties and instances were compared with (a) the intermediate relations, attributes and tuples respectively; and (b) the DSpace data model entities (i.e. communities, subcommunities and collections), items’ metadata fields and items’ metadata values respectively. After evaluating the generated ontology, its instances were compared with the individuals, which were translated and expressed with respect to the VIVO ontology.

5.1.1. Relation to ontology transformation

Dataset 1

Table 3 shows the schema of intermediate database and the ontology (i.e. the target model) that were created for the DSpace data model (i.e. the source model) entities and items’ metadata fields. There are two steps of the transformation.

Table 3.

Dataset 1: Summary of results – ontology creation.

DSpace data model (source model)		Extracted intermediate database		OWL ontology (target model)
Communities, collections, items, metadata fields and metadata values		Entities, attributes and tuples		OWL classes, properties and instances
Main communities	3	Primary entities	3	Primary classes	3
Subcommunities (with non-empty collections)	10	Subentities	10	Subclasses	10
Non-empty collections	15	Subentities	15	Subclasses	15
Metadata fields (complex)	3	Weak primary entities	3	Subclasses	3
Metadata fields (multivalued)	5	Weak secondary entities	5	Datatype property	5
Metadata fields (not multivalued)	11	Non-key attributes	14	Datatype property	14
		Primary keys (not foreign key)	11	Functional datatype property with minCardinality=1	6
		Primary keys (foreign keys)	33	Functional object property with minCardinality=1	28
Total items in 15 collections	2242	Total tuples of $R_{CL}$ (relations corresponding to collections)	2242	Total instances of $C_{CL}$ (classes corresponding to $R_{CL}$ )	2242

In the first step, three main communities in DSpace data model were transformed into three primary entities (PE) of the intermediate database. The primary entities do not contain any foreign key as a part of primary key because they are strong entities [18]. Twenty-five subcommunities and collections were transformed into 25 subentities (SE). A subentity is a weak-entity; therefore it has a foreign key as a part of its composite primary key. Three metadata fields (complex) were transformed into weak primary entities (WPE). The primary key of WPE contains foreign keys as its part and the relation also has non-prime attributes [18]. Five metadata fields (multivalued) were transformed into weak secondary entities (WSE). Each WSE has the composite primary key which is composed of two attributes. One of them is also a foreign key and one is not a foreign key. There are no non-key attributes in WSE [18]. Eleven metadata fields (not multivalued) and three non-key attributes of metadata fields (complex) were converted into 14 non-key attributes. There are 11 (i.e. 3 PE + 3 WPE + 5 WSE) primary keys or parts of composite primary keys (i.e. not foreign key), 33 (i.e. 25 SE + 3 WPE + 5 WSE) primary keys (i.e. foreign keys) and 2242 tuples.

In the second step, three PE and 25 SE were transformed into primary classes and subclasses respectively. Three WPE were also transformed into subclasses. Five WSE were transformed into datatype properties because they do not have non-key attributes. They were deducted from primary (not foreign key) and primary (foreign key). Then six primary keys (not foreign keys) and 28 primary key (foreign key) were transformed into six functional datatype properties and 28 functional object properties with minCardinality 1, respectively. A total of 2242 instances were created for tuples.

Dataset 2

Table 4 shows details of the DSpace data model, the schema of intermediate database and the ontology. There are two steps of the transformation. In the first step, 1 main community in DSpace data model was transformed into one PE of the intermediate database. Sixteen subcommunities and collections were transformed into 16 subentities (SE). One metadata field (complex) was transformed into weak primary entity (WPE). Two metadata fields (multivalued) were transformed into weak secondary entities (WSE). Twelve metadata fields (not multivalued) and one non-key attribute of metadata field (complex) were converted into 13 non-key attributes. There are four (i.e. 1 PE + 1 WPE + 2 WSE) primary keys or parts of composite primary keys (i.e. not foreign key), 19 (i.e. 16 SE + 1 WPE + 2 WSE) primary keys (i.e. foreign keys) and 533 tuples.

Table 4.

Dataset 2: summary of results – ontology creation.

DSpace data model (source model)		Extracted intermediate database		OWL ontology (target model)
Communities, collections, items, metadata fields and metadata values		Entities, attributes and tuples		OWL classes, properties and instances
Main communities	1	Primary entities	1	Primary classes	1
Subcommunities (with non-empty collections)	9	Subentities	9	Subclasses	9
non-empty collections	7	Subentities	7	Subclasses	7
Metadata fields (complex)	1	Weak primary entities	1	Subclasses	1
Metadata fields (multivalued)	2	Weak secondary entities	2	Datatype property	2
Metadata fields (not multivalued)	12	Non key attributes	13	Datatype property	13
		Primary keys(not foreign key)	4	Functional datatype property with minCardinality=1	2
		Primary keys (foreign keys)	19	Functional object property with minCardinality=1	17
Total items in 15 collections	533	Total tuples of $R_{CL}$ (relations corresponding to collections)	533	Total instances of $C_{CL}$ (classes corresponding to $R_{CL}$ )	533

In the second step, one PE and 16 SE were transformed into primary classes and subclasses, respectively. One WPE was also transformed into subclass. Two WSE were transformed into datatype properties because they do not have non-key attributes. They were deducted from primary (not foreign key) and primary (foreign key). Then two primary keys (not foreign keys) and 17 primary keys (foreign keys) were transformed into two functional datatype properties and 17 functional object properties with minCardinality 1 respectively. A total of 533 instances were created for tuples.

Dataset 3

Table 5 shows details of the DSpace data model, the schema of intermediate database and the ontology. There are two steps of the transformation. In the first step, onw main community in the DSpace data model was transformed into one PE of the intermediate database. Eighteen subcommunities and collections were transformed into 18 subentities (SE). One metadata field (complex) was transformed into weak primary entity (WPE). Three metadata fields (multivalued) were transformed into weak secondary entities (WSE). Nine metadata fields (not multivalued) and one non-key attribute of metadata field (complex) were converted into 10 non-key attributes. There are five (i.e. 1 PE + 1 WPE + 3 WSE) primary keys or parts of composite primary keys (i.e. not the foreign key), 22 (i.e. 18 SE + 1 WPE + 3 WSE) primary keys (i.e. foreign keys) and 100 tuples.

Table 5.

Dataset 3: summary of results – ontology creation.

DSpace data model (source model)		Extracted intermediate database		OWL ontology (target model)
Communities, collections, items,metadata fields and metadata values		Entities, attributes and tuples		OWL classes, properties and instances
Main communities	1	Primary entities	1	Primary classes	1
Subcommunities (with non-empty collections)	8	Subentities	8	Subclasses	8
Non-empty collections	10	Subentities	10	Subclasses	10
Metadata fields (complex)	1	Weak primary entities	1	Subclasses	1
Metadata fields (multivalued)	3	Weak secondary entities	3	Datatype property	3
Metadata fields (not multivalued)	9	Non key attributes	10	Datatype property	10
		Primary keys (not foreign key)	5	Functional datatype property with minCardinality=1	2
		Primary keys (foreign keys)	22	Functional object property with minCardinality=1	19
Total items in 15 collections	100	Total tuples of $R_{CL}$ (relations corresponding to collections)	100	Total instances of $C_{CL}$ (classes corresponding to $R_{CL}$ )	100

In the second step, one PE and 18 SE were transformed into primary classes and subclasses respectively. One WPE was also transformed into subclass. Three WSE were transformed into datatype properties because they do not have non-key attributes. They were deducted from primary (not foreign key) and primary (foreign key). Then two primary keys (not foreign keys) and 19 primary keys (foreign keys) were transformed into two functional datatype properties and 19 functional object properties with minCardinality 1, respectively. A total of 100 instances were created for tuples.

The results of all the three datasets show that information is preserved in transformation. It reflects that the transformation is correct.

5.1.2. Ontology data translation

Dataset 1

Table 6 shows that eight classes of DSpace ontology that were created corresponding to communities and subcommunities, were matched and translated as instances of the matched class. The remaining five subcommunities’ classes did not find any corresponding class in VIVO, so they were not mapped. Fifteen collections’ classes of DSpace ontology were matched and their 2242 instances were completely translated into VIVO. Three subclasses that were created for complex metadata fields (having 240 metadata values/instances) in DSpace ontology were mapped on Person classes in VIVO and their 240 individuals were created.

Table 6.

Dataset 1: summary of results – data translation.

Generated ontology (source model)		VIVO ontology (target model)
Classes		Matched VIVO individuals
Primary classes	3	Academic department	3
Subclasses (corresponding to subcommunities)	10	Laboratory	5
Subclasses (corresponding to collections)	15	Report	6
		Thesis	8
		Article	1
Subclasses (corresponding to complex attributes)	3	Person	3
Instances		Identified VIVO individuals
Total instances of $C_{CL}$ (classes corresponding to collections)	2,242	Report	272
		Thesis	1,969
		Article	1

Dataset 2

Table 7 shows that three classes of DSpace ontology that were created corresponding to communities and subcommunities were matched and translated as instances of the matched class. The remaining seven subcommunities’ classes did not find any corresponding class in VIVO, so they were not mapped. Seven collection classes of DSpace ontology were matched and their 533 instances were completely translated into VIVO. One subclass, which was created for complex metadata fields (having 76 metadata values/instances) in DSpace ontology, was mapped on Person class in VIVO and its 76 individuals were created.

Table 7.

Dataset 2: summary of results – data translation.

Generated ontology (source model)		VIVO ontology (target model)
Classes		Matched VIVO individuals
Primary classes	1	School	1
Subclasses (corresponding to SubCommunities)	7	Academic departments	2
Subclasses (corresponding to Collections)	7	Reports	3
Subclasses (corresponding to Collections)	7	Theses	4
Subclasses (corresponding to Complex attributes)	1	Person	1
Instances		Identified VIVO individuals
Total Instances of $C_{CL}$ (classes corresponding to collections)	533	Reports	70
	533	Theses	463

Dataset 3

Table 8 shows that three classes of DSpace ontology, which were created corresponding to communities and subcommunities, were matched and translated as instances of the matched class. The remaining six subcommunities’ classes did not find any corresponding class in VIVO, so they were not mapped. Ten collection classes of DSpace ontology were matched and their 100 instances were completely translated into VIVO. One subclass that was created for complex metadata fields (having 28 metadata values/instances) in DSpace ontology was mapped on Person class in VIVO and its 28 individuals were created.

Table 8.

Dataset 3: summary of results – data translation.

Generated ontology (source model)		VIVO ontology (target model)
Classes		Identified VIVO individuals
Primary classes	1	School	1
Subclasses (corresponding to subcommunities)	8	Academic departments	2
Subclasses (corresponding to collections)	10	Reports	2
		Theses	3
		Articles	2
		Conference paper	2
		Book	1
Subclasses (corresponding to complex attributes)	1	Person	1
Instances		Identified VIVO individuals
Total Instances of $C_{CL}$ (classes corresponding to collections)	100	Reports	32
		Theses	23
		Articles	12
		Conference paper	18
		Book	15

In VIVO ontology, classes have already been created and only instances can be translated into it after matching the classes. The matching and translation of classes and their instances are semi-automatic processes in our system. The classes of DSpace ontology that were created, corresponding to communities and subcommunities were translated as the instances of matched classes in VIVO ontology because they do not have any instances. Whereas the instances of those classes of DSpace ontology that were created corresponding to collections are basically the items of DSpace database, they were translated as the instances of the matched class in VIVO. Some subcommunities have no corresponding class in VIVO, because VIVO and DSpace are both autonomous ontologies, so complete mapping is almost impossible. Therefore the classes could not map to any class. However, this information loss has no effect in VIVO ontology because these classes have no instances in DSpace ontology. Items of DSpace are the most important and they were translated completely. The results of all three datasets show that information is preserved in data translation. This shows that the data translation is correct.

5.2. System accuracy

The correctness of the system is based on the exactness and completeness, which are measured with precision, recall and F-measure [38].

5.2.1 Relation to ontology transformation

The ontologies produced by DSont system for Datasets 1–3 are shown in Figures 10, 11 and 8 respectively. The arrows show a super-class/subclass relation in the figures, for example, contributer_architecture is a subclass of dept_of_architecture in Figure 11. We compared our proposed technique to transform a DSpace database with that of Astrova [12] because it is the most similar technique which uses almost the same transformation rules that we used in our transformation system. Since this system is not publicly or commercially available, we thoroughly studied this technique and its rules, which were used for transformation. We applied this technique directly on a DSpace database. Astrova generates ontology classes according to the DSpace database schema without considering the data model of an institute that is hidden in the DSpace database. It produced the same ontology for all three datasets. A portion of the ontology is shown in Figure 12.

Figure 10.

Ontology produced by the proposed system (Dataset 1).

Figure 11.

Ontology produced by the proposed system (Dataset 2).

Figure 12.

Ontology produced by Astrova’s [12] technique.

In this ontology, community, subcommunity, collection and item classes are not linked with each other, so the ontology does not depict that an item belongs to a particular collection, community. It does not show the relationship of authors and their publications in a specific collection or community. Ontology classes have been generated for associative tables, such as community2_community and community2_collection. They are normally adjusted in class properties. This generated ontology does not preserve the hierarchy of the data model. Correct classes need to be extracted from the contents of these relations. The ontology is very odd and does not portray the accurate data model of the repository. Therefore, this ontology is not helpful in discovering information from the repository for sharing purpose. On the other hand, item (e.g. masters), collection (e.g. theses_architecture) and contributor (e.g. contributor_architecture, i.e. author, editor and adviser of master’s theses) of a community (e.g. dept_of_architecture) are linked in the ontologies produced by the DSont system. These ontologies represent accurate data models of the respective repositories. It can be concluded that the existing transformation techniques cannot generate an accurate ontology for DSpace database if they are directly applied on the database. We did not consider to compute precision, recall and F-measure because they are useless in this case.

5.2.2. Ontology data translation

The results of the ontology data translation were evaluated using precision, recall and F-measure measurements. Precision is the number of correct results divided by the number of all returned results and Recall is the number of correct results divided by the number of results that should have been returned. In our project, they are calculated as follows:

\begin{matrix} Precision & = & \frac{| T \cap^{R} |}{R} \end{matrix}

(1)

\begin{matrix} Recall & = & \frac{| T \cap^{R} |}{E} \end{matrix}

(2)

where T represents the translated instances/properties, R represents the retrieved instances/properties and E represents the expected instances/properties that should have been translated. The F-measure is defined as the harmonic mean of precision and recall. It is calculated as follows:

\begin{matrix} F - measure & = & 2 \frac{Precision * Recall}{Precision + Recall} \end{matrix}

(3)

The instances and properties of the mapped classes were matched and expressed with respect to the target ontology. Tables 9 –11 show the results after evaluating the translated instances and properties of Datasets 1–3, respectively. The tables illustrate that instance translation gives the best precision, which is 100%; this is due to the reason that system translated all the instances properly and expressed with respect to the target ontology. These instances were transformed into the instances of corresponding mapped classes that are later used to populate the VIVO ontology (i.e. target ontology).

Table 9.

Dataset 1: evaluation results for accuracy of the data translation process.

VIVO classes	Instances
VIVO classes	E	R	T	Precision	Recall	F-measure
Academic department	3	3	3	1.00	1.00	1.00
Laboratory	5	5	5	1.00	1.00	1.00
Report	272	272	272	1.00	1.00	1.00
Thesis	1969	1969	1969	1.00	1.00	1.00
Article	1	1	1	1.00	1.00	1.00
	Properties
Academic department	12	12	12	1.00	1.00	1.00
Laboratory	20	20	20	1.00	1.00	1.00
Report	1360	1088	816	0.75	0.60	0.67
Thesis	9845	7876	5907	0.75	0.60	0.67
Article	6	5	3	0.60	0.50	0.55

Table 10.

Dataset 2: evaluation results for accuracy of the data translation process.

VIVO classes	Instances
VIVO classes	E	R	T	Precision	Recall	F-measure
School	1	1	1	1.00	1.00	1.00
Academic department	2	2	2	1.00	1.00	1.00
Report	70	70	70	1.00	1.00	1.00
Thesis	463	463	463	1.00	1.00	1.00
	Properties
School	4	4	4	1.00	1.00	1.00
Academic department	8	8	8	1.00	1.00	1.00
Report	350	350	210	0.60	0.60	0.60
Thesis	2315	2315	1389	0.60	0.60	0.60

Table 11.

Dataset 3: evaluation results for accuracy of the data translation process.

VIVO classes	Instances
VIVO classes	E	R	T	Precision	Recall	F-measure
School	1	1	1	1.00	1.00	1.00
Academic department	2	2	2	1.00	1.00	1.00
Report	32	32	32	1.00	1.00	1.00
Thesis	23	23	23	1.00	1.00	1.00
Article	12	12	12	1.00	1.00	1.00
Conference paper	18	18	18	1.00	1.00	1.00
Book	15	15	15	1.00	1.00	1.00
	Properties
School	4	4	4	1.00	1.00	1.00
Academic department	8	8	8	1.00	1.00	1.00
Report	160	160	96	0.60	0.60	0.60
Thesis	115	115	69	0.60	0.60	0.60
Article	72	72	36	0.50	0.50	0.50
Conference paper	108	108	54	0.50	0.50	0.50
Book	90	90	45	0.50	0.50	0.50

In the translation of properties, it was observed that the translated properties are less than the extracted and expected ones. As discussed earlier, VIVO and DSpace are autonomous ontologies. Some metadata fields in DSpace ontology are not important for VIVO. Therefore, no corresponding properties were found in VIVO ontology. Therefore these properties were not translated in VIVO. This shows some loss of information, which becomes a reason for the lower precision and recall scores. Still these properties are present in DSpace ontology and can be mapped onto any other target ontology which has corresponding properties. Table 12 depicts the average precision, recall and F-measure scores for all the datasets. It shows that the precision is 100% in the case of instance translation whereas it is 80% in translating properties of these instances.

Table 12.

Average evaluation result for accuracy of ontology data translation

	Average precision	Average recall	Average F-measure
Instances	100	100	100
Properties	80	73.67	75

6. Conclusion

The aim of this research is to share the information of an existing IR with other information systems within the institution or outside to help the community in discovering common interests and making connections. To achieve this goal, we need to transform an IR relational database into an ontology because it represents a data source at the higher level of abstraction and integrate its data with the target ontology, such as VIVO for sharing and reusing information for knowledge discovery. However, the existing relation to ontology transformation systems produces odd results if they are applied on a DSpace database because its schema is a meta-schema, not a normalized schema. A DSpace database relation cannot be mapped to an ontology class because a class has to be created for a data model entity that is preserved in the database relations. Therefore, it is necessary to extract the data model from the DSpace database prior to transforming it into an ontology. This makes the transformation novel compared with the typical relational to ontology transformation. Moreover, some of the existing systems do not create a proper parent–child hierarchy (i.e. generalization and specialization) between classes of an ontology and some others do not appropriately handle multivalued attributes of database relations in transformation and lose data semantics. In addition, the ontology created from a DSpace database needs to be aligned with the target ontology, for example, VIVO in order to populate its data into the ontology. This was achieved by identifying or establishing semantic correspondence between entities (i.e. classes and properties) of both of the autonomous ontologies.

We implemented the transformation system in Java and generated an OWL ontology using Jena-2.6.4 Ontology API for the DSpace data model. The evaluation criteria of the proposed system are: (a) preservation of information capacity; and (b) transformation accuracy. Three datasets were used for the evaluation of our system. The proposed system transformed all of the items in a DSpace database into instances of an ontology classes and then they were translated and expressed with respect to the target ontology. In both the transformation and translation of properties, it was observed that the translated properties are less than the extracted and expected ones. This shows some loss of information, which becomes a reason for the lower precision and recall scores. The essence of this loss is that VIVO and DSpace are both autonomous ontologies, so complete mapping between them is almost impossible. Therefore, corresponding properties were not found in the VIVO ontology. Therefore these properties were not translated in VIVO; however these properties are present in DSpace ontology and can be mapped onto any other target ontology that has corresponding properties whenever it is required. Moreover the focus of the proposed transformation system is on DSpace, thus it has not been applied on other existing institutional repositories systems. The proposed system may not be equally applicable in them owing to their specific database schemas. In the proposed system, simple mapping was generated by a user between the source ontology and VIVO ontology for data translation. An ontology matching technique has not been applied for creating the mapping. It consumes time and needs a great deal of involvement of a domain expert. It can be improved by applying an existing matching technique, such as Alasoud et al. [39] and Akbari and Fathian [40] for creating the mapping between ontologies.

Footnotes

Acknowledgements

We would like to thank Mr Amjad Usman and Dr Kashif Rajpoot of the School of Electrical Engineering and Computer Science, National University of Sciences and Technology, for their assistance.

Funding

This work is made possible with the funding support provided by National University of Sciences and Technology, Islamabad, Pakistan.

Notes

References

Futrelle

Gaynor

Plutchak

. Semantic middleware for e-Science knowledge spaces. Concurrency and Computation: Practice and Experience 2011; 23(17): 2107–2117.

Russell

Day

. Institutional repository interaction with research users: a review of current practice. New Review of Academic Librarianship 2010; 16(S1): 116–131.

Tiropanis

Davis

. Semantic technologies for learning and teaching in the Web 2.0 Era. IEEE Intelligent Systems 2009; 24(6): 49–53.

Krafft

Cappadona

Caruso

. Vivo: Enabling national networking of scientists. In: Proceedings of web science conference 2010 (WebSci’10), Raleigh, NC, April 2010, pp. 1310–1313.

McCue

Chiang

Lowe

. VIVO: Connecting people, creating a virtual life sciences community. D-Lib Magazine 2007; 13(7/8): 1–16.

Wache

Voegele

Visser

. Ontology-based integration of information – a survey of existing approaches. In: Proceedings of IJCAI-01 workshop: Ontologies and information sharing, Washington, GA, August 2001, pp. 108–117.

Thakuria

. Building an institutional repository with DSpace. In: Proceedings of 6th convention planner, Nagaland, India, November 2008, pp. 102–114.

Khan

Usman

Irfan

Hayat

. DSpace@ SEECS: SEECS institutional repository system. In: Proceedings of 7th international conference on emerging technologies (ICET 2011), Islamabad, Pakistan, September 2011, pp. 1–6.

Tansley

Smith

Walker

. The DSpace open source digital asset management system: Challenges and opportunities. In: Proceedings of 9th European conference on research and advanced technology for digital libraries (ECDL 2005), Vienna, September 2005, pp. 242–253.

10.

Tansley

Bass

Stuve

. The DSpace institutional digital repository system: current functionality. In: Proceedings of the 3rd ACM/IEEE-CS joint conference on digital libraries, Houston, TX, May 2003, pp. 87–97.

11.

Albarrak

Sibley

. Translating relational and object-relational database models into OWL models. In: Proceedings of the IEEE international conference on information reuse and integration (IRI 2009), Las Vegas, NV, August 2009, pp. 336–341.

12.

Astrova

Korda

Kalja

. Rules for Mapping SQL Relational Databases to OWL Ontologies. In: Proceedings of the 2nd international conference on metadata and semantics research, Corfu Island, Greece, October 2007, pp. 415–424.

13.

Bizer

Cyganiak

. D2R Server-publishing relational databases on the semantic web (poster). In: 5th international Semantic Web conference (ISWC 2006), Athens, GA, November 2006, p. 26.

14.

Cerbah

. Mining the content of relational databases to learn ontologies with deeper taxonomies. In: Proceedings of 2008 IEEE/WIC/ACM international conference on web intelligence and intelligent agent technology workshops (WI-IAT 2008), Sydney, NSW, December 2008, pp. 553–557.

15.

Cullot

Ghawi

. DB2OWL: A tool for automatic database-to-ontology mapping. In: Proceedings of the fifteenth Italian symposium on advanced database systems (SEBD 2007), Torre Canne, Fasano, Italy, June 2007, pp. 491–494.

16.

Laborda CP

Conrad

. Relational. OWL: A data and schema representation format based on OWL. In: Proceedings of the 2nd Asia-Pacific conference on conceptual modelling, Newcastle, Australia, January/February 2005, pp. 89–96.

17.

Nyulas

OConnor

. DataMaster – A plug-in for importing schemas and data from relational databases into Protege. In: Proceedings of the 10th international protege conference, Budapest, July 2007, http://protege.stanford.edu/conference/2007

18.

Khan

Sonia

. R2O: Relation to ontology transformation system. Journal of Information and Knowledge Management (JIKM) 2011; 10(1): 71–89.

19.

Stella

. The VIVO Ontology: Enabling networking of scientists. In: Proceedings of the 3rd international conference on web science (ACM WebSci’11), Koblenz, Germany, June 2011, pp. 1–2.

20.

Alhajj

. Extracting the extended entity-relationship model from a legacy relational database. Information Systems 2003; 28(6): 597–618.

21.

Maatuk

Ali

Rossiter

. Semantic enrichment: The first phase of relational database migration. In: Proceedings of 4th international joint conferences on computer, information, and systems sciences, and engineering (CISSE 2008), Bridgeport, December 2008, pp. 373–378.

22.

Gherabi

Addakiri

Bahaj

. Mapping relational database into OWL Structure with data semantic preservation. International Journal of Computer Science and Information Security 2012; 10(1): 42–47.

23.

Nagy

Seth

. Data extraction from web tables: The devil is in the details. In: Proceedings of 11th international conference on document analysis and recognition (ICDAR 2011), Beijing, September 2011, pp. 242–246.

24.

Kappel

Kapsammer

Kargl

. Lifting metamodels to ontologies: A step to the semantic integration of modeling languages. In: Proceedings of 9th International conference on model driven engineering languages and systems (MoDELS 2006), Genova, Italy, October 2006, pp. 528–542.

25.

Astrova

Korda

Kalja

. Storing OWL ontologies in SQL relational databases. International Journal of Electrical, Computer and Systems Engineering 2007; 1(4): 242–247.

26.

Curino

Orsi

Panigati

Tanca

. Accessing and documenting relational databases through OWL ontologies. In: Proceedings of international conference on flexible query answering systems (FQAS), Roskilde, Denmark, October 2009, pp. 431–442.

27.

Bizer

Seaborne

. D2RQ-treating non-RDF databases as virtual RDF graphs (poster). In: 3rd international Semantic web conference (ISWC 2004), Hiroshima, Japan, November 2004, p. 26.

28.

Aumueller

Massmann

Rahm

. Schema and ontology matching with COMA++. In: Proceedings of the ACM SIGMOD international conference on management of data, Baltimore, MD, June 2005, pp. 906–908.

29.

Engmann

Maßmann

. Instance Matching with COMA++. In: Proceedings of the workshop on Datenbanksysteme in business, technologie and web (BTW 2007), Aachen, Germany, March 2007, pp. 28–37.

30.

Araújo

Hidders

. SERIMI – Resource description similarity, RDF instance matching and interlinking. In: Proceedings of the 6th international workshop on ontology matching, Bonn, Germany, October 2011, pp. 246–247.

31.

Castano

Espinosa

Ferrara

. Multimedia interpretation for dynamic ontology evolution. Journal of Logic and Computation 2008; 19(5): 859–897.

32.

Castano

Ferrara

Montanelli

Lorusso

. Instance matching for ontology population. In: Proceedings of the sixteenth Italian symposium on advanced database systems (SEBD 2008), Mondello, Italy, June 2008, pp. 121–132.

33.

Castano

Ferrara

Montanelli

. Matching ontologies in open networked systems: Techniques and applications. Journal on Data Semantics 2006; 25–63.

34.

Knoblock

Szekely

Ambite

. Semi-automatically mapping structured sources into the Semantic Web. In: Proceedings of the 9th extended Semantic Web conference (ESWC 2012), Heraklion, Greece, May 2012, pp. 375–390.

35.

Lafferty

McCallum

FCN Pereira . Conditional random fields: Probabilistic models for segmenting and labeling sequence data. In: Proceedings of the 18th international conference on machine learning (ICML 2001), Williamstown, MA, June 2001, pp. 282–289.

36.

Embley

Liddle

. KBB: A knowledge-bundle builder for research studies. In: Proceedings of 2nd international workshop on active conceptual modeling of learning (ACM-L 2009), Gramado, Brazil, November 2009, pp. 148–157.

37.

Miller

Ioannidis

Ramakrishnan

. The use of information capacity in schema integration and translation. In: Proceedings of the 19th international conference on very large data bases (VLDB), Dublin, August 1993, pp. 120–133.

38.

Zhang

Chen

. Application-oriented purely semantic precision and recall for ontology mapping evaluation. Knowledge-based Systems 2008; 21(8): 794–799.

39.

Alasoud

Haarslev

Shiri

. An empirical comparison of ontology matching techniques. Journal of Information Science, August 2009, 35(4): 379–397.

40.

Akbari

Fathian

. A novel algorithm for ontology matching. Journal of Information Science, June 2010, 36(3): 324–334.