Leveraging Semantic Web Technologies for Enterprise Information Integration

3.1 Organization of information

The OI layer needs to manage all data, including historical data, and changes in the data structure. To make this possible, we categorize enterprise data according to its characteristics and define guidelines for the data schema for each category.

3.1.1 Categories and characteristics of enterprise data

There are five categories of enterprise data according to [8]: (1) master data, (2) operational data, (3) unstructured data, (4) analytical data, and (5) metadata. Master data represents essential business entities and is used in many different information services. Operational data has two types: transactions and inventory. Both are generated in the daily operations of a business, but the former is normally described as an add operation while the latter is described as an update operation [9]. Typical examples of unstructured data are text data, portable document format files (PDFs) and other documents, and data for websites. Analytical data and metadata is derived from the other types of data and is highly reusable.

In this article, we focus on master data, the core data in business. Master data in our laboratory is employees, departments, research topics, and re- search achievements. Operational data associated with this master data is research papers, patents, research products, technical assistance, and technical disclosures.

3.1.2 Master data with historical data

Each information service has its own dialect. Integrating data in different information services requires some data processing such as merging data with the same meaning and eliminating inconsistencies. A typical master data management (MDM) [10] method for integrating data at a point adds a unique identifier (ID) (primary key (PK)) to each record and uses this PK as a reference from records of other tables. Data in one system might have been consistent with data in other systems at some point in the history (but may not be now); however, historical data is deleted if it is not used. Changes to data schemas and a lack of historical data make it difficult to integrate enterprise information.

3.1.3 Master data schema design

We describe a master data schema for integrated master data, including historical data. In addition to the requirements of MDM, this schema should:

(1) manage historical data in a simple manner and

(2) handle schema changes such as attribute addition and deletion easily.

Historical data can be managed by storing all of the data either periodically or when any changes occur. The drawbacks of this method are storing redundant data and needing to have extra free space for attributes that might be added in the future.

We classify attributes into two types—(1) ones that are necessary to identify a particular instance of each entity and (2) the rest—and store them separately: attributes in category (1) are stored in a main table and those in category (2) are stored in separate sub-tables (one sub-table for each attribute) [11]. In this way, when attribute values have changed, we only need to add a record to the sub-tables; and when an attribute is added or changed, we only need to create a new sub-table and do not need to change the main table.

Here, we give an example of employees’ master data. It is possible to treat only the employee ID as the main attribute, but attributes such as department ID and title also need to be treated as main attributes to identify a particular employee with his or her associated time. Therefore, we decided to manage employee ID, department ID, and job title in the main table and all the other attributes such as telephone number, fax number, and email address in its corresponding sub-tables.

An example of a master table of employees with historical data is shown in Fig. 2, which shows the main table and other sub-tables with PKs of the main table for reference. The main table consists of ID as a PK, the expiry date of each record (start and end dates), and the values of other attributes needed to identify a particular record. In the main table, we also include attributes that will not change before the ID expiry dates. Each sub-table contains ID (a PK of the main table), the value of the corresponding attribute, and its expiry date (start and end dates).

Fig. 2. Example of employees' master table with historical data.

To update the value of an attribute, one must change the end date of its previous record and add a new record of a new value and a new expiry date. Since sub-tables exist for each attribute other than the ones in the main table, a new attribute could be added to the master data by just adding a new sub-table, and an attribute could be deleted by just changing the end date values of the corresponding sub-table if necessary.

Therefore, this master data schema will make it possible to handle attribute changes with historical data easily.

3.2 Distribution of information

3.2.1 Background

The DI layer processes and edits data from the OI layer to provide desired data to the UI layer in a desired format. As mentioned in section 2, the UI layer should be able to retrieve data without knowing its structure in the OI layer. Therefore, the requirements of the DI layer are as follows:

(1) hide the data structure in the OI layer from the UI layer

(2) reach the desired data easily

(3) retrieve the attributes of an entity easily.

We convert data in the RDB to the RDF format, which is free from the RDB schema. RDF is a metadata data model defined by the World Wide Web Consortium (W3C), and one possible query language for RDF, is SPARQL [12], which is also defined by W3C. When we use RDF, naming the uniform resource identifier (URI) is a known problem like choosing the proper vocabulary. However, we do not have to worry about this problem because the data in the OI layer always has unique IDs, which can be used as URIs.

Using RDF changes the second and third requirements above into:

(2') express attributes of an entity simply

(3') express relations between entities simply

We discuss how to fulfill these requirements in section 3.2.2 and show an example of the utilization of information in section 3.3.

3.2.2 Information model for distribution

It is easy to express an RDB schema that changes over time (i.e., through column addition and deletion) in RDF format because properties in RDF format represent columns (attributes) in an RDB [13]. By using the RDF format, we aim to represent changes in RDB schemas as simply as possible. To do so, we define both columns (attributes) and relationships between tables in an RDB as properties between resources in RDF format, and the only information that we disclose to users is the properties to represent the relationship between tables. In this way, we can represent RDB schemas using properties of each resources even if RDB schemas have been changed.

An example of data in RDF format that is equivalent to the RDB data in Fig. 2 is shown in Fig. 3. In our model, we define our own vocabulary because it is for enterprise use. The properties representing relationships between tables in the RDB include emp:org, emp:log, emp:currentLog, and emp:prevLog, and the other properties representing RDB columns include emp:name, emp:title, emp:room, emp:phone, and emp:mail. Regardless of changes in the RDB schemas with time, the resources connected with emp:log, emp:currentLog, or emp:prevLog properties maintain their RDB schemas at that point and have an expiry date as a property.

Fig. 3. RDF data representing employees.

The three abovementioned requirements ((1), (2'), and (3')) are fulfilled through the introduction of a simple hierarchical expression like this. For example, a query for selecting all attributes of a particular employee at a given point in time is as simple as the one in Fig. 4.

Fig. 4. Query to retrieve all properties of specified employee.

3.3 Utilization of information

As knowledge management services, there are some services like ResearchMap [14] which allow researchers to introduce their skills and research outcomes in a cross-sectional manner. However, using knowledge management services in the style of a social network system (SNS) in companies is usually problematic. Motivating employees to update their profiles is as difficult as searching for and comparing information objectively. Therefore, we developed a way to find employees with a specified condition objectively by using integrated enterprise data. A screen image of our KnowWho service is shown in Fig. 5.

Fig. 5. Screen image of KnowWho.

All the data in the screen image in Fig. 5 was retrieved from the DI layer by using the SPARQL endpoint. In Fig. 5, the employee’s master data shown at the top resulted from a query that searched for an entity using a given employee’s name as a search keyword, and retrieved its properties to represent attributes and their values. Similarly, KnowWho retrieved related keywords––search entities for a given employee’s name and their values of the keyword property. In order to retrieve research pa- pers, KnowWho searches research paper entities using a given employee’s name. Only the paper titles are shown in Fig. 5, but it is possible to show other related information about the research papers as well. The historical data can be retrieved by searching for entities using a given employee’s name, tracing emp:prevLog properties, and getting the values by using emp:org properties.

By using a simple hierarchical model, such as the one described in section 3.2, we can establish services without knowing the RDB schema. Changing the RDB schema over time causes conditional branching in search operations. Therefore, search operations are simpler when data is in RDF format, which can represent RDB columns as properties.