Transformation From Semantic Data Model to Rdf

There have been several efforts to use relational model and database to store and manipulate Resource Description Framework (RDF). They have one general disadvantage, i.e. one is forced to map the model of semantics of RDF into relational model, which will end up in constraints and additional properties, such as, validating each assertion against the RDF schema which also stored as a triplets table. In this paper, we introduce Semantic Data Model as a proposed data model language to store and manipulate Resource Description Framework. This study also tries to prescribe the procedure on transforming a semantic data model into a RDF data model. Keyworsd: Semantic Data Model, Resource Description Framework.


INTRODUCTION
Until recently, several efforts have been taken to use relational model and database to store and manipulate Resource Description Framework [6], namely specs loyal, explicit models, hashed with origin, and the naïve approach. The "specs loyal" approach [2], which was proposed by Jonas Liljegren, attempts to provide a compact way of implementing every detail in the RDF model and schema specifications. Its database schema is implemented in Postgres. The "explicit models" approach [3], which was proposed by Brian McBride, treats models explicitly and makes use of views. Its database schema is implemented on Oracle. The "hashed with origin" approach [4], was proposed by Sergey Melnik, where it make used of CRC64 hash values to treat models explicitly. Its database schema is implemented in MySQL. Or the "naïve" approach, where all triplets are stored in one table that has three fields: Property, Resource, and Value.
These approaches have one general disadvantage, i.e. one is forced to map the model of semantics of RDF into relational model, which will end up in constraints and additional properties, such as, validating each assertion against the RDF schema which also stored as a triplets table.
The Semantic Data Modeling (SDM) [8] is built on the concept of semantics, which is also the concept used in RDF. This similarity enables them to be mapped into each other. Both, SDM and RDF, make use of semantics concept. Therefore the mapping will be done more smooth and with less constraints and additional properties. Another advantage of this approach is we can use the Xplain system [8], which built on SDM, as the storage system for the RDF resources, since Xplain has advantages over relational databases.
The main purpose of this paper is described how a data model, i.e. semantic data model, can be mapped into RDF and whether both are adequate to represent each other. This paper is organized as follows. Section 2 gives a brief overview of the SDM. Section 3 describes the transformation from SDM into RDF. Finally, the last section gives a summary and lists several conclusions.

SEMANTIC DATA MODELING
The concept of semantics is the main issue in Semantic Data Modeling (SDM) [8]. It is all about interrelationships between formal definitions and their relationships with the real world that being modeled. But in SDM, only the interrelationships between formal definitions (data), which form information, are formalized in the conceptual model. The following are the basic concepts behind the SDM: -A conceptual model consists only of positive statements (assertions). It means that a statement must be true since it should correspond to the reality. Therefore, for example, data of a person who is not working a company will never be stored in the table employee. -Each type definition is unique, meaning that there is no different type definition with the same name of the same collection of attributes. -An attribute is related to one and only one type, and a type is related to at least one attribute. An attribute value is related to one and only one instance in the related type. -An object can be either a type or an instance of a type, depending on the point of view. A type is a set of objects that have definite properties.
Attributes of a type are the properties that aggregate that type. An instance of a type is an object that has the properties of that type. For example: type employee = name, sex, department type department = name, location The definition of the model has not yet contained information about any base type, which is the type of which the attributes are no longer relevant. The base types appeared in the above model can be defined as the following: base name (A20) base sex (A1) base location (A40)

AGGREGATION
A type (e.g. employee) is defined as a collection (aggregation) of characteristics (name, birth_date, address, department, etc) called attributes. It also can be stated that an attribute is part of a type definition.
The semantic model shown in Figure 2 can be written as the following type definitions: type employee = name, birth_date, address, department type GHSDUWPHQW «

SPECIALIZATION AND GENERALIZATION
Type specialized_A is a specialization of type A, if type specialized_A is type A with at least one additional attribute. And the counterpart of specialization is generalization. The semantic model shown in Figure 3 can be written as the following type definitions:

TRANSFORMATION TO RDF
The main purpose of this section is to describe the mechanism to transform a semantic data model into data models with the standard Semantic Web languages, i.e. Resource Description Framework (RDF). In this section we use the following conventions for describing the RDF Graph:

Aggregation
A type (i.e. employee) is defined as a combination (aggregation) of a number of characteristics (name, address, department, etc) called attributes. It also can be stated that an attribute is a part of a type definition.
The RDF data model in Figure 4.b. cannot represent the semantic data model in Figure 4.a flawlessly. The property its_department cannot model the N-to-1 relation between type employee and department as viewed in the semantic data model shown in Figure 4.a. This is because in RDF, any instance of rdf:Property represents an M-to-N relation, and RDF does not provide any mechanism to define cardinality of a property.
The above definition shows that an attribute of a type is defined in the same manner regardless whether it is a base attribute or not.
Consider a system where an employee works on some projects, and a project is done by several employees. This means that type employee and type project have M-to-N relation. The system is defined as the following: type workon = employee, project type employee = name, .. type project = name,...
The first RDF data model alternative has the following characteristics: -The N-to-1 relation between resource workon and other resources (employee, project, and status) can not be satisfied, since any instance of rdf:Property represents M-to-N relation. -It assumes that every type in the semantic data model is transformed as an instance of rdfs:Class.
The second RDF data model alternative has the following characteristics: -It really represents the M-to-N relation between employee and project and at the same time reducing the need to create bigger model in RDF. -Since the model is smaller than the first alternative, therefore the data will also be more compact. It also means the data is easier to manage and the query construction is simpler. -It assumes that every type in the semantic data model is transformed as an instance of rdfs:Class, except those types that represent Mto-N relations between other two types. These types are represented as instances of rdf:Property.

Figure 9. Recursive type
Consider a recursive type shown in Figure 9, which defines as the following type definitions:
This solution also rises a problem of incorrect relation cardinality with the fact that rdf:Property represents M-to-N relation instead of N-to-1 relation.

Specialization and Generalization
Type specialized_A is a specialisation of type A, if type specialized_A is a type A with one or more additional attributes. And the counterpart of specialization is generalization.