KR20130064160A - System of entity-relationship model reformulation of sparql query results on rdf data and the method - Google Patents

Abstract

PURPOSE: A system for transforming an entity relation of an SPARQL query result about RDF data by using ontology schema information and a method thereof are provided to efficiently visualize a concept element by mapping the query result with an entity relation model. CONSTITUTION: A query result extracting module(210) extracts a query graph and a query result corresponding to a variable included in a query condition from an XML(eXtensible Markup Language)/RDF(Resource Description Framework) database system managing ontology schema data in an RDF type. A type generating module(220) generates a type of a query result by using a schema of the query result and the query graph. An inheritance module(230) determines a corresponding number for a relation of the type and performs inheritance to the relation to generate an entity relation model. [Reference numerals] (200) Entity-relation model based visualization system; (210) Query graph and result extracting module; (220) Type generating module; (230) Inheritance module; (240) Model reducing module; (250) Visualizing module; (260) Query result and entity-relation model storage unit; (300) XML/RDF database system; (AA) Query and query result schema extracting request; (BB) Query graph, query result, and schema information; (CC) Ontology schema + Instance

Description

Entity system of transformation of SPALR query results on RDF data and its method {SYSTEM OF ENTITY-RELATIONSHIP MODEL REFORMULATION OF SPARQL QUERY RESULTS ON RDF DATA AND THE METHOD}

The present invention relates to a system and method for transforming SPARQL query results on RDF data, and more particularly, to conceptually map SPARQL query results to directional entity-relationship models using ontology schema information of SPARQL query results. The present invention relates to a system and method for transforming entity relationships of SPARQL query results for RDF data that can be effectively visualized.

Ontology is a formalized way of describing the concepts and relationships between them in a particular domain. Ontology consists of classes representing concepts and properties representing relationships between concepts, and expresses knowledge through the connection between them. Ontology is widely used in the information science field such as semantic web and knowledge management, and recently, it is used in various fields such as medicine and e-commerce.

For ease of management and retrieval of ontology, many studies present ontology data in a structured form triple following the RDF format of (subject, predicate, object). The user can retrieve ontology data using the SPARQL query language with a query condition in the form of triple conjunctions.

In order for the user to easily interpret the SPARQL query results and obtain useful knowledge, the query results need to be visualized effectively. Well-known ways to visualize SPARQL query results are table-based visualization and graph-based visualization.

Table-based visualization is a visualization method that merges SPARQL query results into tuples and lists them in one table, and is used in ontology editors such as protease and allegrograph. Table-based visualization groups all the query results into a common table, making it difficult to grasp the relationship between the query results and also difficult to interpret the meaning of the query results.

Graph-based visualization is to visualize the query results in a graph structure. The subjects and objects belonging to the query results are visualized as nodes and the predicates are edged. In the case of graph-based visualization, if the structure of the visualized graph is simple, it may be helpful to interpret the meaning of the query result by referring to the nodes and the connection relationships between the nodes in the graph. However, the complexity of the graph structure makes it difficult to interpret the meaning of query results, as is table-based visualization.

As a method of simplifying the SPARQL query result visualized by the graph structure, Sundrar et al. Proposed a method of simplifying the graph by visualizing a set of nodes called focal points. Specifically, among the outgoing edges of the node in focus, the edges having the same label (that is, predicate) and the nodes connected to the edges are merged into one edge and one node, respectively. We first showed the nodes that are one point away from the focus and the focus, and can browse the merged nodes and edges step by step. Step-by-step browsing reduces the amount of query results shown at a time to help you identify the results. However, since the nodes are visualized around the focus, it is still difficult to interpret the meaning of the entire query results and the relationship between the nodes that do not belong to the focus and the validity of the visualization depends on the focusing user.

Existing visualization methods are sometimes contextual information that is thought to be important to the user to understand the meaning of the query results, that is, the entities, attributes, and relationships that are needed to describe the results at the conceptual level. It does not show the back effectively.

1 illustrates a table-based visualization and a graph-based visualization according to the related art. As shown in FIG. 1, the SPAQRL query results for the employee information of the company, the department to which each employee belongs, and the project information are visualized by using an allegrograph, a commercial ontology editing tool. As (a) is a result of table-based visualization, all query results are grouped into one table and visualized. Therefore, it is difficult to interpret not only the meaning of the query results but also the relationship between the results. (b) is a graph-based visualization result. The result is visualized by a graph in which the subject and object of the result are nodes and the predicate is an edge. The connection relationship between nodes on the result graph obtained through this method can be used to interpret the query results. However, when the graph becomes complicated, it is difficult to identify the connection relationship, which makes it difficult to understand the meaning of the result.

According to the present invention, an object relation transformation system of SPARQL query results for RDF data capable of visualizing conceptual elements by mapping SPARQL query results to directional entity-relationship models using ontology schema information of SPARQL query results; The purpose is to provide a method.

In order to achieve the above object, the object-relationship model-based visualization system according to the present invention includes a query graph and a query result corresponding to a variable belonging to a query condition of a SPARQL query from an XML / RDF database system that manages ontology schema data in an RDF format. A query result extraction module for extracting a; A type generation module for generating a type of a query result using a query graph extracted from the query result extraction module and a schema of the query result; An inheritance module for determining a corresponding number of relationships among the types generated by the type generation module and generating an object-relationship model by performing inheritance on the object type and the relationship of a parent-child relationship; A model reduction module for merging predetermined relationships with an entity type having a 1: 1 relationship from the entity-relationship model generated in the inheritance module; It is characterized in that it includes a visualization module for visualizing by grouping the query results according to the mapped concept elements.

Here, the query graph corresponding to the variable belonging to the query condition extracted from the query result extraction module and the query result are stored, and the object types, attributes, and relationships generated from the type generation module, the inheritance module, and the model reduction module are stored. It is characterized in that it further includes a main memory unit for storing.

Here, each node of the query graph extracted by the query result extracting module corresponds to a subject, an object, and a predicate, which are each triple of a query condition, and a gID for distinguishing a variable corresponding to the triple, and the preple at the query condition. Its feature is that it consists of isConst, an identifier that distinguishes whether the value corresponding to is a variable or constant, and the name of the value appearing in the query condition.

Here, the type generation module designates a type for each element of the query result data, specifies a domain class and a range class of data corresponding to a property among the query result data, and then sets a data structure for an object type, a relationship, and an attribute. Its characteristics are that it creates and stores it in query result and object-relationship model storage.

In this case, the inheritance module designates the parent-child relationship between the object type and the relationship using the inheritance property between the conceptual elements of the query result, and determines the number of correspondences of each relationship by using the constraint property. After storing the information of the relationship, the characteristic is that it inherits the information of the parent object type (or relationship) to the child object type (or relationship).

Here, the constraint property for determining the corresponding number of user-defined properties mapped to the relationship of the inheritance module is characterized in that it uses a cardinality restriction property and a function / inverse function restriction property that impose a specific constraint. There is this.

Here, the model reduction module creates a directional graph having an object type as a node and a user-defined property as a directional edge from the object relation model of the query result, and all output edges have a 1: 1 correspondence and have two or more different ones. This feature is characterized by recursively merging a node that does not have an incoming edge from the node and an edge having a 1: 1 correspondence input to the node.

In addition, the object-relationship model-based visualization method according to the present invention for achieving the above object, using the ontology schema data to extract the query graph and query results corresponding to the variables belonging to the query condition, and to each tuple of the query structure Initializing the data; Generating a type of the extracted query result; Determining a number of correspondences for the relationships among the generated types, and generating an entity-relationship model by performing inheritance on entity types and relationships of parent-child relationships; Minimizing the entity-relationship model by merging certain types of relationships with the entity type having the 1: 1 relationship from the generated entity-relationship model; It is characterized in that it comprises the step of visualizing by grouping the query results in a predetermined unit based on the concept element of the entity-relationship model.

Wherein the initializing step comprises: generating the tuples and attributes of the tuples; Initializing the variables; It is characterized in that it comprises the step of assigning a component of each tuple of the extracted query graph as a component of the query structure.

Here, if the attribute of the query structure is a variable, the characteristic is that the result of the query is stored in the attribute and initialization is performed for the rest.

In this case, the tuple is returned when the tuple initialization is completed for all tuples of the query graph.

The type generating step may include specifying a type of result data for each tuple of the query result; Designating a domain and range relationship of the query result data; It is characterized in that it comprises the step of creating an entity type, attribute and relationship according to the query result data.

The step of specifying the type of the query result is characterized in that the type is corrected while processing the system-defined properties.

Here, in the step of specifying the type of the query result, a query for obtaining an attribute type of the query result is performed, and when the type is a class, the class name is set as the type with the classification as CL.

Herein, in the step of specifying the type of the query result, a query for obtaining an attribute type of the query result is performed. When the type is a user-defined property, the data type property and the object property are divided, and the object property is OP. The distinction is that the name is specified as the type and the data type property is specified as DP.

Here, in the step of specifying the type of the query result, if the result of the query for obtaining the type is an empty set, the characteristic is that the type is designated as a constant that does not exist.

Here, in the processing of the system-defined property, it is checked whether the query result value of the system-defined property is located in the predicate of the query condition, and the characteristic is that it is designated as a subject class or an object class according to the property type. have.

Here, in the step of specifying the domain and range relationship of the query result data, obtain a class belonging to the domain and range of the data of which the classification of the query result is a data type property and an object property and store it in the class list of the domain and the range. When a property appears in a predicate of a query condition, the property is that the type of data corresponding to a subject and an object is limited to be included in the domain and range class obtained above.

The generating of an entity type, an attribute and a relationship according to the query result data may include: finding data having a class as a class from the query result, and generating an entity type corresponding to the type of data; Generating a data structure for storing the query result from the input query structure and storing the data structure in the generated entity type; Storing the created entity in a set of entity types; Creating an object for the object property and storing the query result; Creating an attribute when creation of the entity type and relationship is complete; The method includes obtaining a domain class and data value of the property, creating an attribute in the domain class, and storing a query result related to the attribute in the corresponding class.

In this case, the inheritance relationship designation for the relationship among the generated types is to find a pair of classes having a parent-child relationship, and if an object type corresponding to the pair of classes exists, the name of the parent object type is registered in the child object type. This feature is unique in that it registers the name of the child object type with the parent object type.

Here, the correspondence number designation for determining the correspondence number may include: specifying a function and an inverse function restriction for properties; Retrieving a constraint of an object type and a constraint of a given relationship (ie, a user-defined property) and a range object type of the relationship for each object type (ie, a class); It is characterized in that it includes a step of determining the corresponding number of properties by searching for a corresponding restriction and a function and an inverse function restriction for each relationship.

Herein, the entity type and relationship inheritance of the parent-child relationship may include inheriting all information of the parent relationship to the child relationship and deleting the parent relationship; Registering the inherited relationship with a domain entity type and storing information (query result) of the relationship; It is characterized in that it includes the step of inheriting all information (relationships, properties, and query results) of the parent entity type to the child entity type and then deleting the parent entity type.

The reducing of the entity-relationship model may include: initializing a variable of an entity type used for model reduction; Checking whether the entity type can be merged with another entity type by model reduction; Calculating the number of relationships in which the entity type belongs to a range to determine the model reduction entity type; It is characterized in that it comprises the step of performing a model reduction from the entity type having the number of the relationship is 0 and has a 1: 1 correspondence.

In this case, when the connection between the entity type and the relationship forms a cycle, the method may further include performing model reduction from the entity type having a 1: 1 correspondence among the entity types that are not reduced.

The visualizing may include mapping an entity storing a result of a variable indicated in a query condition among query results stored in each entity type, and generating a table for the entity; Retrieving a relationship between the entity types for which the table is generated and generating a directional edge from a table corresponding to a domain entity type of a relationship to a table corresponding to a range entity type of a relationship; After querying the query result stored in the object type in which the table is created, filling the query result corresponding to the variable of the query condition with the attribute value of the corresponding table, outputting the result and directional edges of tuples of different tables having the same tuple ID The feature is that it includes a step of connecting to.

According to the present invention, conceptual elements can be visualized effectively by mapping query results to directional entity-relationship models using ontology schema information of the query results.

1 is a diagram illustrating conventional table-based visualization and graph-based visualization.
2 is a diagram schematically illustrating the configuration of an entity-relationship model based visualization system according to the present invention.
3 shows an example before and after model reduction according to the invention;
4 is a flow chart for an entity-relationship model based visualization method in accordance with the present invention.
5 illustrates an example of visualization of an entity-relationship model in accordance with the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. However, in describing in detail the operating principle of the preferred embodiment of the present invention, if it is determined that the detailed description of the related known function or configuration may unnecessarily obscure the subject matter of the present invention, the detailed description thereof will be omitted.

The same reference numerals are used for portions having similar functions and functions throughout the drawings.

In addition, in the entire specification, when a part is referred to as being 'connected' to another part, it may be referred to as 'indirectly connected' not only with 'directly connected' . Also, to include an element does not exclude other elements unless specifically stated otherwise, but may also include other elements.

Hereinafter, an embodiment of the present invention will be described in detail with reference to the accompanying drawings.

2 is a diagram schematically showing the configuration of an entity-relationship model based visualization system according to the present invention. As shown in FIG. 2, the entity-relationship model based visualization system 200 according to the present invention corresponds to a variable belonging to a query condition of a SPARQL query from an XML / RDF database system that manages ontology schema data in an RDF format. A query result extraction module 210 for extracting a query graph and a query result, and a type generation module 220 for generating a type of query result using the schema of the query graph and the query result extracted by the query result extraction module 210. ) And an inheritance module 230 that determines the number of correspondences among the types generated by the type generation module 220 and generates an object-relationship model by performing inheritance on the object type and the relationship of the parent-child relationship. ) And a model reduction module 24 for merging predetermined relationships with an entity type having a 1: 1 relationship from the entity-relationship model generated by the inheritance module 230. 0), the visualization module 250 for visualizing grouping the query result according to the mapped concept element, and the query graph and the query result corresponding to the variable belonging to the query condition extracted from the query result extraction module 210. And a query result and an object-relationship model storage unit for storing and storing an object type, an attribute, and a relationship generated from the type generation module 220, the inheritance module 230, and the model reduction module 240. .

The query result extraction module 210 initializes the necessary data structure for maintaining the query result, collects the query result, and stores the data result in the data structure. That is, all the result data of variables included in the query condition of the SPARQL query are visualized.

The query condition is expressed as a join of <subject, predicate, object>, which is a triple, and the same variable may appear in multiple triples. Therefore, it is necessary to parse a query in order to determine which variable is an element of the query result, and whether data elements having the same value are the same variable.

The query graph parsed from the XML / RDF database, which is the ontology storage system 300, is collected and utilized. Each node of the query graph corresponds to each triple of the query condition, and gID is a unique key that distinguishes a subject (object) and a variable (or constant) corresponding to a predicate. It is composed of isConst, an identifier that distinguishes whether a value corresponding to a subject, an object, and a predicate is a variable or a constant, and name, which is a value appearing in a query condition. In the present invention, this information of the query graph is used to define an internal data structure that stores the query structure and the query results.

The query result extraction module 210 utilizes type properties, configuration properties, and constraint properties to determine object types, properties, and relationships. Type properties are properties that determine the types of properties and classes. Configuration properties determine the types of objects that participate in a relationship in the object-relationship model. Finally, the constraint property determines the mapping cardinality of the relationship. In addition, there are container properties that represent containers, such as collections and bags, and annotation properties, which represent annotation information for classes and properties. In the present invention, for the sake of simplicity, all user-defined properties are considered, but among the system-defined properties, only the inheritance, type, configuration, and constraint property processing methods necessary for expressing query results in an object-relational model are presented. do.

Terms meaning domain Set of classes (or object types) belonging to the domain of a property (or relationship) range Set of classes (or object types) belonging to the property (or relationship) range Domain class The class belonging to the property's domain Range class The class belonging to the property's range Domain object type Object type belonging to the domain of the relationship Range Object Type Object type belonging to the relation range Domain instance An instance of a domain class (or object type) Range instance An instance of a range class (or object type) 1: 1 correspondence 1-to-1 correspondence 1: 1 correspondence chain Consecutive pairs of <class (or object type), property (or relationship)> with a 1: 1 match

On the other hand, Table 1 is defined for the terms used in the present invention, it will be referred to for understanding the terms.

In general, ontology schemas expressed in languages such as RDF and OWL, which are standardized by the W3C, are largely divided into classes and properties. A property is defined as the relationship between a class (simply, a domain class) that is an element belonging to its domain, and a class (simply, a range class) or data type that is an element belonging to a range, and an object property, The data type is divided into data type properties. In addition, depending on who defined the property, properties defined in the standard can be divided into system-defined properties, and user-defined properties can be divided into user-defined properties. System-defined properties can be classified according to their role. Inheritance properties are properties that specify inheritance relationships between classes or between properties and are used to determine parent-child (ie, IS-A) relationships in the object-relationship model.

The type generation module 220 maps the schema of the query result to entity types, relationships and attributes of an entity-relationship model. Specifically, the type is specified for each element of the query result data, and the domain class and range class of the data corresponding to the property are specified among the query results. Finally, we create data structures for object types, relationships, and attributes and store the query results in the corresponding data structures. In this case, the class maps to an object type, the data type property among user-defined properties maps to the domain object type property of the property, and the object property maps to a relationship. The data type determined at this stage is a candidate type, and the type is adjusted through the inheritance and model reduction steps described below.

The inheritance module 230 finds an inheritance (ie, parent-child) relationship between conceptual elements of the query result and inherits parent information to the child. Specifically, the inheritance property is used to specify the parent-child relationship between the object type and the relationship, and the constraint property is used to determine the corresponding number of each relationship. After storing the relationship information in the domain object type, 4) information of the parent object type (or relationship) is inherited by the child object type (or relationship).

In order to determine the number of correspondences of a user-defined property that is mapped to a relationship, the present invention provides a constraint that imposes a restriction between a property and the domain class of the property, and a correspondence that is a property that imposes a specific constraint on that property. cardinality) and property / inverse function restriction properties.

The corresponding constraint property is used to specify the number of correspondences that any instance of the domain class that is constrained by the constraint has an instance or data value of the range class of the constrained property. The correspondence restriction property is composed of maximum correspondence (MaxCardinality), minimum correspondence (MinCardinality), and correspondence (Cardinality). Here, the maximum correspondence represents the maximum number of range instances (0 or 1), the minimum correspondence represents the minimum number of range instances (0 or 1), and finally the correspondence represents the number of range instances (0 or 1). For example, if the maximum correspondence of any property is 1, any domain instance corresponds to at most one range instance. Since more than one domain instance can correspond to the same range instance, the corresponding number of properties is 1: 1 or n: 1. In addition, if the minimum number of correspondences is 1, it means that any domain instance corresponds to one or more range instances. Therefore, the number of correspondences of the property may be 1: 1, 1: n, n: 1, and n: m. .

The function / inverse function restriction property is used to correct the correspondence determined using the corresponding restriction property. This property consists of a Functional Property and an InverseFunctionalProperty. Functional properties indicate that the relationship from the restricted set of instances of the domain class to the set of instances of the range class has a functional relationship. Inversely, the inverse property indicates that the relationship from the instance set of the range class to the instance set of the domain class has a functional relationship. For example, the maximum number of correspondences is 1, and the number of correspondences for any property that has an inverse relationship between the domain and the range class is 1: 1.

                 value
Kinds One 0 Minimum response All correspondences All correspondences Maximum correspondence 1: 1 or n: 1 Not used Response 1: 1 or n: 1 Not used

Correspondence number
Kinds 1: 1 or n: 1 All correspondences Use functional properties 1: 1 or n: 1 1: 1 or n: 1 Use Inverse Function Properties 1: 1 1: 1 or 1: n Use both function and inverse properties 1: 1 1: 1 Do not use both function and inverse properties 1: 1 or n: 1 1: 1, 1: n, n: 1, or n: m

Table 2 shows the number of correspondences of the user-defined properties determined by the corresponding restriction properties, and Table 3 shows the number of correspondences of the user-defined properties when the function and inverse function restriction properties are applied to the corresponding number determined in Table 2. Expressed in bold in Table 3 is the final number of correspondences.

The model reduction module 240 reduces the complexity of the query result expressed in the entity-relationship model. Reduce the type 1: 1 mapping chain to a pair of <object type, relationship> or <object type, the property of that object type>. For example, as shown in Figures 1 and 2, the employee class Emp has a relationship with the name object type through a property called name with a 1: 1 counterpart, which is an fn with a 1: 1 counterpart. The data type properties ln and ln describe the names of specific employees. In this case, the name property, the name object type, and the fn and ln properties form a 1: 1 correspondence chain. In the present invention, as shown in Fig. 2, name, f. Create fn and name.ln and convert each to an attribute of the employee entity type, following the conversion rules described in Creating Types.

To this end, the present invention creates a directional graph having an object type as a node and a user-defined property as a directional edge from the object relationship model of the query result. Then, all output edges have a 1: 1 correspondence only and repeatedly merge nodes having no corresponding incoming edges from two or more different nodes and a 1: 1 correspondence input to the node. . The path expression for the names of the edges before the merge is defined as the name of the edge of the merge result. For simplicity, the invention assumes that different entity types are not linked to the same entity type through the same relationship.

3 is a diagram showing an example before and after model reduction according to the present invention. As shown in Figure 3, the rectangles represent the entity type and the directional edges represent the relationship. And the label of the edge shows the edge name (correspondence). Model reduction begins with a node with no input edges, which corresponds to node 1 and node 7. Nodes shared by the output edges of node 1 and node 6, such as node 2, cannot have their edges merged with them. In this case, model reduction is performed again from that node (node 2 in this example). Also, if there are no edges with a 1: 1 correspondence among the output edges such as node 4 or if there are edges with other correspondences as well as edges with a 1: 1 correspondence on the output edge such as node 5, such nodes also It cannot be merged with an edge that is input to a node and, as mentioned previously, redeploy the model from that node (eg nodes 4 or 5). In the example, the models mentioned by e ₁ and e ₂ , e ₃ and e ₄ , and e ₉ and e ₁₁ , which are edges with 1: 1 correspondence of nodes 2 and 3, nodes 7 and 8, and nodes 5 and 6 Merged by satisfying the condition of reduction.

4 is a flowchart of an entity-relationship model based visualization method according to the present invention.

Initialization step

First, as shown in FIG. 4, a query graph and a query result corresponding to a variable belonging to a query condition are extracted using ontology schema data, and an initialization is performed for each tuple of the query structure (S401).

More specifically, Algorithm 1 is the main algorithm for entity-relational transformation. In this algorithm, we initialize the tuple ID of the query result and the variable to store the entity, relationship, number of matches, and query result (line 1). For each tuple of query results, the result data type, domain, and range relationship are specified (lines 4-6), and the results are stored in resultList (lines 7). Next, create an object type, a relationship, and an attribute according to the type of the result data (line 9), perform the correspondence calculation and inheritance (line 10-12), and reduce the object-relationship model to determine the correspondence relationship information. Returned with ERCardinalityMap (lines 13-14). The data structure of this information consists of a set of tuples <property p, domain class d, range class r, and the corresponding number of property cvalue> tuples, used for model reduction and visualization. This series of processes can be described by dividing into four stages as described above: initialization, type creation, inheritance, and model reduction.

Algorithm ER _ REFORMULATION
IN :
queryList // Query graph that is a set of <gID, name, isConst>
queryResult // set of query result tuples <v ₁ ... v _m >
OUT :
EntitySet // Set of entity types containing the query result
ERCardinalityMap // Set of object types, relationships and their correspondences
1: EntitySet : = RelationshipSet : = ERCardinalityMAP : = resultList : = Φ
2: tupleID : = 0
3: for each tuple v ∈ queryResult
4: tuple : = INITIALIZE_TUPLE ( tupleID , queryList , v )
5: SET_TYPES (tuple attrs.)
6: SET_DOMAIN_RANGE (tuple attrs, ERCardinalityMap .)
7: add tuple to resultList
8: tupleID : = tupleID + 1
9: MAKE_RESULTLIST ( resultList , EntitySet , RelationshipSet , AttributeSet )
10: SET_PARENT_CHILD ( EntitySet , RelationshipSet )
11: SET_CARDINALITY ( RelationshipSet , ERCardinalityMap )
12: INHERITANCE ( EntitySet , RelationshipSet , ERCardinalityMap )
13: MODEL_REDUCTION ( EntitySet , ERCardinality .

Algorithm 1. Object-relational transformation algorithm.

As in Algorithm 2, the initialization of the query structure is to initialize the tuples constituting the query structure. Create a tuple and its properties (lines 1-2), and initialize variables (lines 3-4). Then, the elements of each tuple of the input query graph are assigned to the elements of the query structure (lines 6-7). If the attribute of the query structure is a variable, the result of the query is stored in the attribute (lines 8-9) and the rest of the initialization is executed (lines 10-15). When all tuples in the query graph have been initialized, the tuple is returned (line 16).

Algorithm INITIALIZE _ TUPLE
IN :
tupleID // Tuple ID to initialize
queryList // Query graph that is a set of <gID, name, isConst>
v // query result tuple <v _{1 , ...} v _m >
OUT :
tuple // query structure
1: create tuple // Create query structure
2: create attr // create attribute of query structure
3: i : = j : = tupleID : = 0
4: tuple . tupleID : = tupleID
5: for each t ∈ queryList
6: attr . tripleID : = tripleID ; attr . gID : = t. gID ;
7: attr . name : = t. name ; attr . isConst : = t. isConst
8: if ( attr . IsConst = false ) // save query result
9: attr . name : = v _j ; j : = j +1
10: set attr . pos to S if ( i = 0), attr . pos to P if ( i = 1), and, otherwise, attr . pos
to O.
11: attr . group : = UN
12: attr . typeList : = attr . domainList : = attr . rangeList = Φ
13: add attr to tuple . attrs
14: if (attr pos = O .) TripleID: = (tripleID + 1) mod 3
15: i : = ( i + 1) mod 3
16: return tuple

Algorithm 2. Initialization of tuples that make up the query structure.

Type creation step

Generating the type of the extracted query result is performed (S402). The type generating step is largely composed of type designation (algorithm 3), domain and range designation (algorithm 4), and generation of object types, attributes, and relationships (algorithm 5).

As seen in Algorithm 3, the type specification of the query result is divided into the process of specifying the type and the process of correcting the type while processing system-defined properties. Type specification is performed on attributes (lines 3-4) whose type is not included in the system-defined property set (SP_SET) among the attributes of the input query structure tuple. First, run a query to find the type of the property (line 6). If the type is a class, specify the classification as CL and the name of the class as the type (lines 7-8). If the type is a user-defined property, the data type property and the object property are processed according to different procedures (lines 9-21). For object properties, set the division to OP and the property name to type (lines 10-12). For data type properties, the division is set to DP (line 14), and if the property is located in the predicate of the query condition, the type of data value corresponding to the object is a constant (lines 16-17). Finally, a single type query is used to process data such as instances of a class whose type cannot be determined (lines 18-26). If the attribute type belongs to the term set OWL_RDF_SET defined in the RDF and OWL standards, it is not processed because it is a type not covered by the present invention (line 19). If the result of a query for a type is an empty set, then the type is a constant because the type does not exist (lines 20-22). In the case of an instance where the type is determined to be a class by executing the query for the type twice (lines 23-25), the classification is set to CL, and the names of the classes that are the result of the first query to find the type of the instance (lines 26). ).

As mentioned above, the present invention only handles type properties, configuration properties, inheritance properties, and constraint properties, which are system-defined properties that affect the determination of conceptual elements such as the type and relationship of an entity. Type and configuration properties are processed during type creation, while inheritance and constraint properties are handled in the next step, inheritance. The next step in the type specification process is to process the system-defined properties as follows: First, for a query result whose classification is a system-defined property, we check whether the query result value is located in the predicate of the query condition. If the property is a type property (lines 29), it specifies that the type of the subject of that property is an object (lines 34-36). If the property type is a property that determines the domain class of the user-defined property (line 37), then specify the domain of the property corresponding to the subject to be the class of the object type (line 38-43). If the property is to be determined (line 44), the range of properties corresponding to the subject is specified to be a class of object type (lines 45-50).

Algorithm SET _ TYPES
IN :
attrs // Set of attributes of query structure tuple to set type
// class, property, constant type
1: for each attr t ∈ attrs
2: if ( t . Group ! = UN) continue
3: if ( t. Name ∈ SP _ SET )
4: t. group : = SP ; add t. name to t. typeList
5: else
6: SetT : = select? Type where { t. name rdf: type? type}
7: if (owl: Class ∈ SetT )
8: t. group : = CL; add t. name to t. typeList
9: else if (owl: DatatypeProperty ∈ SetT || owl: ObjectProperty ∈ SetT )
10: add t. name to t. typeList
11: if (owl: ObjectProperty ∈ SetT )
12: t. group : = OP
13: else
14: t. group : = DP
15: if ( t. Pos = P)
16: sameID : =
find a tuple from attrs where pos = O and tripleID = t. tripleID
17: sameID . group : = CO; sameID . typeList : = sameID . name
18: else
19: if ( OWL _ RDF _ SET ∩ SetT ! = Φ) continue
20: if ( SetT = Φ)
21: t. group : = CONST; add t. name to t. typeList
22: else
23: for each tuple t ∈ SetT
24: e : = select? Type where { t , rdf: type? Type}
25: if ( e = owl: Class)
26: t. group : = CL; add e. name to t. typeList
// handle system-defined properties
27: for each attr t ∈ attrs
28: if ( t. Group ! = SP) continue
29: if ( t. Name = rdf: type && t. Pos = P)
30: t ₁ : = find a tuple from attrs where tripleID = t. tripleID and pos = S
_{31: if (. T 1 isConst} = true) continue
32: t ₂ : = find a tuple from attrs where tripleID = t. tripleID and pos = O
_{33: if (. T 2 group} = CLASS)
34: SetC : = find tuples from attrs where gID = t ₁ . gID and isConst = false
35: for each tuple c ∈ SetC
36: c. typeList : = t ₂ . name
37: else if ( t. name = rdf: domain && t. pos = P)
38: t ₁ : = find a tuple from attrs where tripleID = t. tripleID and pos = S
_{39: if (. T 1 isConst} = true) continue
40: t ₂ : = find a tuple from attrs where tripleID = t. tripleID and pos = O
41: SetC : = find tuples from attrs where gID = t ₁ . gID and isConst = false
42: for each c ∈ SetC
43: c. domainList : = t ₂ . typeList
44: else if ( t. name = rdf: range && t. pos = P)
45: t ₁ : = find a tuple from attrs where tripleID = t. tripleID and pos = S
46: if ( t _1. IsConst = true ) continue
47: t ₂ : = find a tuple from attrs where tripleID = t. tripleID and pos = O
48: SetC : = find tuples from attrs where gID = t ₁ . gID and isConst = false
49: for each c ∈ SetC
50: c. rangeList : = t ₂ . typeList

Algorithm 3. Type the Query Result.

Algorithm 4 specifies the class that belongs to the domain and range of the object property. First, obtain a class belonging to the domain and range of data whose classification is a data type property and an object property, and store it in the class list of the domain and range (lines 2-7). In the case of data type properties, classes belonging to the range do not exist, so the classes belonging to the range are obtained only for the object properties (lines 5-7). Next, when the property appears in the predicate of the query condition, the data type corresponding to the subject and object is restricted to be included in the domain and range class obtained earlier (lines 8-20). After correcting the type using domain and range information, the ERCardinalityMap data structure stores information that all domain classes have property relationships with all range classes.

Algorithm SET _ DOMAIN _ RANGE
IN :
attrs // Property set of query structure tuple to set type
INOUT :
ERCardinalityMap
// Specify the domain and range class of the property
1: for each tuple t ∈ attrs
2: if ( t. Group ! = OP && t. Group ! = DP) continue
3: domainList : = select? Domain where { t. name rdfs: domain? domain}
4: t. domainList : = domainList
5: if ( t. Group = OP)
6: rangeList : = select? Range where { t. name rdfs: range,? range}
7: t. rangeList : = rangeList
8: if ( t. Pos = P)
9: d : = find a tuple from attrs where pos = S and tripleID = t. tripleID
10: if ( d. Group = CL)
11: d. typeList : = domainList ∩ d. typeList
12: t. domainList : = d. typeList
13: if ( t. Type = OP)
14: r : = find a tuple from attrs where pos = O and tripleID = t. tripleID
15: if ( r. Group = CL)
16: r. typeList : = rangeList ∩ r. typeList
17: t. rangeList : = r. typeList
18: for each d ? t. domainList
19: for each r ? t. rangeList
20: ERCardinalityMap : = ERCardinalityMap U {< t ₁ . name , d , r , nil >}

Algorithm 4. Domain and Range Specification.

Algorithm 5 is an algorithm that creates entity types, relationships, and attributes from query results. First, find the data whose class is class from the query result (lines 1-3), and create an object type corresponding to this data type (lines 5-11). A data structure that stores the query results from the input query structure is created and stored in the created object type (lines 8 and 11). Finally, store the created object in an EntitySet, which is a set of object types (line 9). Similarly, for object properties that are to be converted into relationships, create objects and store query results (lines 12-19). When the creation of the object type and relationship is complete, the property is created. Get the domain class and data value of the data type property (lines 22-24), create an attribute in the domain class (lines 25-29), and store the query results related to the attribute in that class (lines 30 and 32). ).

Algorithm MAKE _ RESULTLIST
IN :
resultList // query result set
INOUT :
EntitySet , // set of object types
RelationshipSet , // relationship set
AttributeSet // attribute set
1: for each tuple t ₁ ∈ resultList
2: for each attr t ₂ ∈ t ₁ . attrs
3: if ( t _2. Group = CL)
4: for each t ₃ ∈ t ₂ . typeList
5: find e from EntitySet whose name = t ₃
6: if ( e = nil )
7: make entity e whose name = t ₃
8: add < t ₁ . tupleID , t ₂ . tripleID , t ₂ . gID , EN, t ₃ . name , t ₂ . isConst ,
t ₂ . pos , nil > to e. tuples
9: add e to EntitySet
10: else
11: add < t ₁ . tupleID , t ₂ . tripleID , t ₂ . gID , EN, t ₂ . name , t ₂ . isConst ,
t ₂ . pos , nil > to e. tuples
12: else if ( t _2. Group = OP)
13: find p from RelationshipSet whose name = t ₂
14: if ( p = nil )
15: make relationship p whose name = t ₂
16: add < t ₁ . tupleID , t ₂ . tripleID . t ₂ . gID , RE, t ₂ . name , t ₂ . isConst ,
t ₂ . pos , nil > to p. tuples
17: add p to RelationshipSet
18: else
19: add < t ₁ . tupleID , t ₂ . tripleID , t ₂ . gID , RE, t ₂ . name , t ₂ . isConst ,
t ₂ . pos , nil > to p. tuples
20: for each tuple t ₁ ∈ resultList
21: for each attr t ₂ ∈ t ₁ . attrs
22: if ( t _2. Group = DP || t _2. Pos = P)
23: domain : = find a tuple from t ₁ . attrs where tripleID = t ₂ . tripleID ,
tupleID = t ₂ . tupleID , and pos = S
24: const : = find a tuple from t ₁ . attrs where tripleID = t ₂ . tripleID ,
tupleID = t ₂ . tupleID , and pos = O
25: for each e ₁ ∈ domain . typeList
26: find e ₂ from EntitySet where name = e ₁
27: if ( e ₂ does not have attribute attr whose name = t _2. Name )
28: make attribute attr whose name = t ₂ . name
29: add attr to e ₂ . AttributeSet
30: add < t ₁ . tupleID , t ₂ . tripleID , t ₂ . gID , AT, t ₂ . name , t ₂ . isConst ,
t ₂ . pos , const . name > to e ₂ . tuples
31: else
32: add < t ₁ . tupleID , t ₂ . tripleID , t ₂ . gID , AT, t ₂ . name , t ₂ . isConst ,
t ₂ . pos , const . name > to e ₂ . tuples

Algorithm 5. Creation of object types, relationships and properties.

Inheritance step

Determining the number of correspondences for the relationship among the generated types, and inheriting the object type and the relationship of the parent-child relationship to generate an object-relationship model (S403). The inheritance stage consists of specifying an inheritance relationship (algorithm 6), matching numbers (algorithm 7), and inheritance (algorithm 8). Algorithm 6 is an algorithm that specifies inheritance relationships, looking for pairs of classes with parent-child relationships (line 1), and if the entity type corresponding to the pair of classes exists in the EntitySet, then the name of the parent object type is the child object type. To the parentList of the child object, and the name of the child object type to the childList of the parent object type. The method of specifying inheritance relationships between properties (lines 5-8) also uses rdfs: subPropertyOf to find parent-child relationships (lines 5) and specifies the inheritance of object types, except searching the RelationshipSet (lines 7). Is the same as

Algorithm SET _ PARENT _ CHILD
INOUT :
EntitySet , // set of object types
RelationshipSet // relationship set
1: SetC : = select? e ₁ ,? e ₂ where {? e ₁ rdfs: subClassOf? e ₂ .
? e ₁ rdfs: type owl: Class.
? e ₂ rdfs: type owl: Class}
2: for each tuple < e ₁ , e ₂ > ∈ SetC
3: if ( EntitySet has both e ₁ and e ₂ classes)
4: add e ₂ to e ₁ . childList ; add e ₁ to e ₂ . parentList
5: SetP : = select? p ₁ ,? p ₂ where {? p ₁ rdfs: subPropertyOf? p ₂ .
? p ₁ rdfs: type owl: ObjectProperty.
? p ₂ rdfs: type owl: ObjectProeprty}
6: for each tuple ( p ₁ , p ₂ ) ∈ SetP
7: if ( RelationshipSet has both p ₁ and p ₂ relationships)
8: add p ₂ to p ₁ . childList ; add p ₁ to p ₂ . parentList

Algorithm 6. Specify Inheritance Relationship.

Algorithm 7 is an algorithm that specifies the corresponding number of properties. First, specify the function and inverse function limits for the properties in the RelationshipSet (lines 1-6). Next, for each object type (i.e., class), look up the constraints of that object type and the constraints of the granted relationship (ie, user-defined properties) and the range object type of that relationship (line 7). Then, the correspondence limit and the function and inverse function constraints are searched for each relationship to determine the corresponding number of properties and reflect them in the ERCardinalityMap (lines 8-18).

Algorithm SET _ CARDINALITY
INOUT :
RelationshipSet , // relationship set
ERCardinalityMap // set of correspondences
1: SetP ₁ : = select? P where {? P rdfs: type owl: FunctionalProperty}
2: SetP ₂ : = select? P where {? P rdfs: type owl: InverseFunctionalProperty}
3: for each p ∈ SetP ₁
4: if ( RelationshipSet has p ) p. func : = true
5: for each p ∈ SetP ₂
6: if ( RelationshipSet has p ) p. invf : = true
7: SetE : = select? D? Res,? P,? Restype,? Val ? R
where {? d rdf: type owl: Class.
? d rdfs: subClassOf? res.
? res rdf: type owl: Restriction.
? res owl: onProperty? pn.
? res? rtype? val.
? pn rdfs:? r}
8: for each tuple t ∈ SetE
9: find map from ERCardinalityMap where p = t. pn , d = td , and r = tr
10: find p from RelationshipSet where name = map .p
11: if ( p. Func = true && p. Invf = true ) map . cvalue : = 1: 1
12: else if ( p. func = true ) map . cvalue : = n: 1
13: else if ( p. Invf = true )
14: if ( t. Restyep = minCardinality) map . cvalue : = 1: n
15: else map . cvalue : = 1: 1
16: else // functional and inversefunctional are both unspecified
17: if ( t. Restyep = minCardinality) map . cvalue : = n: m
18: else map . cvalue : = n: 1

Algorithm 7. Specify the correspondence.

Algorithm 8 inherits all information of parent object type (or relationship) to child object type (or relationship) by referring to parent-child relationship of the specified object type and relationship through inheritance relationship specification. The main algorithm, INHERITANCE, inherits all the information of the parent relationship to child relationships (lines 1-2) and deletes the parent relationships (lines 3-4). It registers the relationship in the domain entity type of the relationship and stores the relationship's information (query result) (lines 5-11). Finally, after inheriting all information (relationships, properties, and query results) of the parent object type to the child object type (lines 12-13), delete the parent object type.

In Algorithm 8, the sub-functions INHERITANCE_PROPERTY and INHERITANCE_CLASS inherit the parent relationship information to the child relationship, respectively, and the parent object type information to the child object type. First, INHERITANCE_PROPERTY finds all child relationships that have a relationship as parent (lines 16-17), stores the query result of the parent relationship in the child relationship, and then the domain and range object types of the parent relationship are the domain and range of the child relationship. Belong to (Ezra 20-22). Finally, the corresponding information of the parent relationship is deleted (line 23). This process is done recursively until the child relationship information no longer exists (line 24).

INHERITANCE_CLASS follows a similar procedure to INHERITANCE_PROPERTY. Save query results, relationships, and properties of the parent object type to the child object type (lines 25-30), and match the child object type to that domain or range for relationship information whose parent object type belongs to the domain or range. After changing the information (lines 31-36), the corresponding information of the parent entity type is deleted (lines 37). This is done recursively for child object types (line 38).

Algorithm INHERITANCE
INOUT :
EntitySet, // set of object types
RelationshipSet, // relationship set
ERCardinalityMap   // set of counterparts
One:SetP : = find relatinships fromRelationshipSet whose parent =nil
2: INHERITANCE_PROPERTY (SetP)
3:for each relationshipp ∈RelationshipSet
4:if(p. childList ! = Φ) removep fromRelationshipSet
5:for each entitye ∈EntitySet
6:for each tuplet _One ∈e. tuples
7:if(e. pos = S)
8: findp fromRelationshipSet having a tuple whose tupleID: =e. tupleID,
9: tripleID =e. tripleID, and pos = P
10: addp. tuples toe. tuples
11: addp toe. RelationshipSet
12:SetP : = find entities fromEntitySet whose parent =nil
13: INHERITANCE_CLASS (SetP)
14:for each entitye fromEntitySet
15:if(e. childList ! = Φ) removee fromEntitySet

AlgorithmINHERITANCE _ PROPERTY
IN :
SetP // set of relationships
16:for each relationshipp ∈SetP
17:SetC : = find relationships fromRelationshipSet whose parent =p. name
18:for each relationshipc ∈SetC
19: addp. tuples toc. tuples
20:Setm : = find maps fromERCardinalityMap where p =p. name
21:for each map ∈Setm
22:ERCardinalityMap : =ERCardinalityMap U
<c. name, map .d, map .r, map . cvalue>
23: delete fromERCardinalityMap where p =p. name
24:if(SetC ! = Φ) INHERITANCE_PROPERTY (SetC)

AlgorithmINHERITANCE _ CLASS
IN :
SetP // set of object types
25:for each entityp ∈SetP 
26:SetC: = find entities fromEntitiySet whose name =p. name
27:for each entityc ∈SetC
28: addp. RelationshipSet toc.RelationshipSet
29: addp. AttributeSet toc. AttirbuteSet
30: addp. tuples toc. tuples
31:Setm : = find maps fromERCardinalityMap where d =p. name
32:for eachmap ∈Setm
33:ERCardinalityMap : =ERCardinalityMap U
<map .p, c. name , map .r, map . cvalue>
34:Setm : = find maps fromERCardinalityMap where r =p. name
35:for eachmap ∈Setm
36:ERCardinalityMap : =ERCardinalityMap U
<map .p, map .d, c. name , map . cvalue>
37: delete fromERCardinalityMap where d =p.nameor r =r. name
38:if(SetC ! = Φ) INHERITANCE_CLASS (SetC)

Algorithm 8. Inheritance of Object Types and Relationships.

Model Reduction Step

From the generated entity-relationship model, the entity-relationship model is reduced by merging an entity type having a 1: 1 relationship with predetermined types and predetermined relationships (S404).

The process of reducing the entity-relationship model will be described in detail in Algorithm 9. Algorithm 9 reduces the schema of query results mapped to the entity-relationship model. The main algorithm, MODEL_REDUCTION, checks whether an object type can be merged with another object type by model reduction (lines 3-6) after initializing the variable of the object type used for model reduction (lines 1-2). At this point, to determine the type of entity to perform model reduction for the first time, we calculate the number of relationships (ie incomingCount) that an entity type belongs to in the range (line 5). Then, model reduction is performed from the object type having the number of relations obtained and having a 1: 1 correspondence (line 7-10). If the association between an object type and a relationship forms a cycle, it cannot be handled in the above step, so the model is reduced from the object type that has a 1: 1 correspondence among the object types that are not reduced by the above processing among the object types. Rerun (lines 11-13).

In Algorithm 9, the subfunction MERGE merges a relationship with a 1: 1 correspondence with its domain and range object types to create a new relationship or attribute. MERGE_TUPLE merges the query results stored in the object types participating in the merging process. First, MERGE searches for a 1: 1 correspondence that has the entity type given as input as the domain entity type and the range entity type of that relationship (lines 15-16). Then, it finds possible merging among the range object types that have not been merged (lines 17-19), and searches both the 1: 1 correspondence of the object types and the range object types of the relationships (lines 20-23). Then, the names of the searched 1: 1 correspondences are merged into the path expression form, and a new relationship and the number of correspondences are generated (lines 24-27). Finally, merge the query results stored in the object types participating in the merge (line 28), delete the corresponding number of object types in the merge (lines 29 and 38), and register the new relationship as a domain object type (line 30). . If the 1: 1 correspondence attempted to merge is a data type property, the correspondence is converted to an attribute of the domain entity type (lines 32-37).

MERGE_TUPLE is an algorithm that merges the query results of the entity types that participated in the merge. It retrieves and deletes all the query results stored in the entity type removed through the merge (lines 39-51). Change the name of the relationship in the query result, the classification of the relationship, and the triple information of the query condition to which the relationship belongs so that the query result of the first object type and the last object type to be merged becomes the query result associated with the newly created relationship (or property). (Lines 41-51) Finally, delete the relationship information that was removed by merging (lines 52-53).

Algorithm MODEL _ REDUCTION
INOUT :
EntitySet , // set of object types
ERCardinalityMap // set of correspondences
1: for each entity e from EntitySet
2: e. incomingCount : = 0; e. tryMerged : = false ; e. isRemovable : = true
3: for each tuple t < p, d, r, cvalue > ∈ ERCadinalityMap
4: find e from EntitySet where name = r
5: e. incomingCount : = e. incomingCount + 1;
6: if ( t. Cvalue ! = 1: 1) e. isRemovable = false
7: root : =
find entity e having incomingCount = 0 and 1: 1 relationships from EntitySet
8: for each entity e ∈ root
9: e. tryMerged : = ture
10: MERGE ( e )
11: root : =
find entity e having tryMerged = false and 1: 1 relationships from EntitySet
12: e. tryMerged : = true
13: MERGE ( e )

Algorithm MERGE
Input :
e // object type
14: for each relationship p ₁ ∈ e. RelationshipSet
15: map ₁ : =
find a tuple from ERCardinalityMap where p = p ₁ . name , d = e. name , and cvalue = 1: 1
16: find entity r ₁ from EntitySet where name = map ₁ . r
17: if ( r _1. TryMerged = true ) continue
18: r ₁ . tryMerged : = true
19: if ( r _1. IsRemovable = false ) MERGE ( r ₁ )
20: if ( r ₁ has relationships)
21: for each relationship p ₂ ∈ r ₁ . RelationshipSet
22: map ₂ : = find a tuple from ERCardinalityMap
where p = p ₂ . name , d = r ₁ . name , and cvalue = 1: 1
23: find entity r ₂ from EntitySet where name = map ₂ . name
24: if ( r _2. IsRemovable = false ) merge ( r ₁ )
25: attr _ name : = p ₁ . name + “.” + p ₂ . name // concatenate
26: make relationship newR whose name = attr _ name
27: add < newR . name , e. name , r ₂ . name , 1: 1> to ERCardinalityMap
28: MERGE_TUPLE ( e , r ₁ , r ₂ , attr _ name , p _1. name , p _2. name )
29: delete < p ₂ . name , r ₁ . name , r ₂ . name , 1: 1> from ERCardinalityMap
30: add new R to e. RelationshipSet
31: else
32: for each attribute p ₂ ∈ r ₁ . AttributesSet
33: attr _ name : = p ₁ . name + “.” + p ₂ . name // concatenate
34: make attribute newA whose name = attr _ name
35: MERGE_TUPLE ( e , r ₁ , nil , attr _ name , p _1. name , p ₂ .. Name )
36: delete < p ₂ . name , r ₁ . name , r ₂ . name , 1: 1> from ERCardinalityMap
37: add new A to e. AttributeSet
38: delete < p ₁ . name , e. name , r ₁ . name , 1: 1> from ERCardinalityMap

Algorithm MERGE_TUPLE
Input :
e , // subject type of the first triple to be merged
r ₁ , // object of the first triple to be merged, and subject type of the second triple
r ₂ , // the type of the object of the second triple to be merged
n_ name , // name of the merged result relation (or attribute)
p ₁ , // name of the relationship that will appear first in the name of the merged result relationship
p ₂ // name of the relationship that will appear later in the name of the result relationship to be merged
39: for each tuple t ₁ in. e. tuples
40: if ( t ₁ .pos! = S) continue
41: find a tuple t ₂ from e. tuples where pos = P, name = p ₁ , tupleID = t ₁ . tupleID
and tripleID = t ₁ . tripleID
42: find a tuple t ₃ from r ₁ . tuples where pos = O, tupleID = t ₁ . tupleID
and tripleID = t ₁ . tripleID
43: find a tuple t ₄ from r ₁ .tuples where pos = S, tupleID = t ₁ and gID = t ₃ . gID
44: find a tuple t ₅ from r ₁ .tuples where pos = P, name = p ₂ , tupleID = t ₁ . tupleID
and triple ID = t ₃ . tripleID
45: if ( r ₂ ! = Nil )
find a tuple t ₆ from r ₂ . tuples where pos = O, tupleID = t ₁ . tupleID
and triple ID = t ₃ . tripleID
46: if ( t _5. Group ! = AT)
47: update t ₂ set name = n_ name
48: update t ₆ set tripleID = t ₁ . tripleID
49: else
50: update t ₂ set group = AT, value = t ₅ . value
51: delete t ₃ , t ₄ , t ₅ from r ₁ . tuples
52: remove from e. RelationshipSet where name = p ₁
53: remove from r ₁ . RelationshipSet where name = p ₂

Algorithm 9. Model Reduction.

Visualization steps

Finally, the step of visualizing by grouping the query result in a predetermined unit based on the concept element of the entity-relationship model (S405). When the entity-relationship model is generated, it is visualized by the following procedure. 5 is a diagram illustrating an example of visualization of an entity-relationship model according to the present invention. As shown in FIG. 5, first, an EntitySet that stores an entity type is searched to find an entity that stores a result of a variable indicated in a query condition among query results stored in each entity type, and generates a table thereof. At this time, the property of the table to be created as the property of the object type is configured. Next, the ERCardinalityMap is searched to find a relationship between the object types in which the tables are created, and a directional edge of a solid line is created from a table corresponding to a domain object type of a relationship to a table corresponding to a range object type of a relationship. For the label of the edge, use the name of the relationship (number of correspondences of the relationship). Finally, after retrieving the query result stored in the object type in which the table is created, the query result corresponding to the variable of the query condition is filled with the property value of the corresponding table, and the result is displayed on the screen and between tuples of different tables having the same tupleID are displayed. Connect with the directional edge of the dotted line.

While the present invention has been particularly shown and described with reference to exemplary embodiments, it is to be understood that the invention is not limited to the disclosed exemplary embodiments, Of course, this is possible. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be defined by the equivalents as well as the claims that follow.

Description of the Related Art
210 --- Query Result Extraction Module 220 --- Type Generation Module
230 --- Inheritance Module 240 --- Model Reduction Module
250 --- Visualization Module 260 --- Storage of Query Results and Object-Relationship Models

Claims (25)

A query result extraction module for extracting a query graph and a query result corresponding to a variable belonging to a query condition of the SPARQL query from an XML / RDF database system that manages the ontology schema data in an RDF format;
A type generation module for generating a type of a query result using a query graph extracted from the query result extraction module and a schema of the query result;
An inheritance module for determining a corresponding number of relationships among the types generated by the type generation module and generating an object-relationship model by performing inheritance on the object type and the relationship of a parent-child relationship;
A model reduction module for merging predetermined relationships with an entity type having a 1: 1 relationship from the entity-relationship model generated in the inheritance module;
And a visualization module configured to visualize the query result by grouping the query result according to a mapped concept element.
The method of claim 1,
Storing a query graph and a query result corresponding to a variable belonging to a query condition extracted from the query result extraction module, and storing object types, attributes, and relationships generated from the type generation module, the inheritance module, and the model reduction module; An entity relationship transformation system of SPARQL query results for RDF data, further comprising a query result and an object-relationship model storage unit.
The method of claim 1,
Each node of the query graph extracted by the query result extraction module corresponds to a subject, an object, and a predicate, which are each triple of a query condition, and includes a gID for distinguishing a variable corresponding to the triple, Transformation of entity relationships in SPARQL query results for RDF data comprising isConst, an identifier that distinguishes whether a value corresponding to the preple is a variable or a constant in a query condition, and a name of a value appearing in the query condition system.
The method of claim 1,
The type generation module,
Specify a type for each element of the query result data, specify a domain class and a range class of data corresponding to a property among the query results, and then generate a data structure for an object type, a relation, and an attribute, and then generate the query result and An entity relationship transformation system of SPARQL query results for RDF data, which is stored in an entity-relationship model storage.
The method of claim 1,
The inheritance module,
Specify the parent-child relationship between the object type and the relationship using the inheritance property between the concept elements of the query result, determine the corresponding number of each relationship using the constraint property, and store the relationship information in the domain object type. And entity relationship transformation system of the SPARQL query result for RDF data, characterized in that inheriting information of a parent entity type (or relationship) to a child entity type (or relationship).
6. The method of claim 5,
The constraint property for determining a corresponding number of user-defined properties mapped to the relationship of the inheritance module uses RDF data and a cardinality restriction property and a function / inverse function restriction property that impose a specific constraint. Entity relationship transformation system of SPARQL query results for.
The method of claim 1,
The model reduction module generates a directional graph having an object type as a node and a user-defined property as a directional edge from the object relation model of the query result, and all output edges have a 1: 1 correspondence and are separated from two or more different nodes. An entity relationship transformation system of a SPARQL query result for RDF data, characterized by repeatedly merging a node having no incoming edge of and an edge having a 1: 1 correspondence input to the node.
Extracting a query graph and a query result corresponding to a variable belonging to a query condition using the ontology schema data, and initializing each tuple of the query structure;
Generating a type of the extracted query result;
Determining a number of correspondences for the relationships among the generated types, and generating an entity-relationship model by performing inheritance on entity types and relationships of parent-child relationships;
Minimizing the entity-relationship model by merging certain types of relationships with the entity type having the 1: 1 relationship from the generated entity-relationship model;
And grouping the query results into predetermined units based on the concept elements of the entity-relationship model to visualize the results of the SPARQL query.
The method of claim 8,
In the initialization step,
Generating the tuples and attributes of the tuples;
Initializing the variables;
And assigning a component of each tuple of the extracted query graph as a component of a query structure.
The method of claim 9,
And if the attribute of the query structure is a variable, storing the result of the query in the attribute and initializing the rest of the query result.
The method of claim 9,
And returning the tuple when the tuple initialization operation is completed for all tuples of the query graph.
The method of claim 8,
The type generating step,
Designating a type of result data for each tuple of query results;
Designating a domain and range relationship of the query result data;
And generating an entity type, an attribute, and a relationship according to the query result data.
13. The method of claim 12,
And specifying a type of the query result comprises correcting the type while processing a system-defined property.
13. The method of claim 12,
In the step of specifying the type of the query result, a query for obtaining an attribute type of the query result is performed, and if the type is a class, the class name is set as the type with the classification CL as SPARQL for the RDF data. How to transform entity relationships in query results.
13. The method of claim 12,
In the step of specifying the type of the query result, a query for obtaining an attribute type of the query result is performed. When the type is a user-defined property, the data type property and the object property are divided, and the object property is OP. An entity relationship transformation method of a SPARQL query result for RDF data, wherein the type is set and the data type property is set to DP.
13. The method of claim 12,
And in the step of specifying the type of the query result, if the result of the query for obtaining the type is an empty set, designating a type as a constant having no type.
The method of claim 13,
In the processing of the system-defined property, check whether the query result value of the system-defined property is located in the predicate of the query condition, and specify the object class or the object class according to the property type. How to transform entity relationships in SPARQL query results.
13. The method of claim 12,
In the step of specifying the domain and range relationship of the query result data,
If the classification of the query result is a class belonging to a domain and a range of data whose data type property and an object property are stored and stored in the class list of the domain and the range, and the property appears in the predicate of the query condition, the subject ( A method of modifying an object relation of a SPARQL query result for RDF data, characterized in that the types of data corresponding to subject) and object are limited to be included in the domain and range classes obtained first.
13. The method of claim 12,
Generating an object type, an attribute, and a relationship according to the query result data may include:
Finding data whose class is a class from the query result and generating an entity type corresponding to the type of data;
Generating a data structure for storing the query result from the input query structure and storing the data structure in the generated entity type;
Storing the created entity in a set of entity types;
Creating an object for the object property and storing the query result;
Creating an attribute when creation of the entity type and relationship is complete;
Obtaining a domain class and data value of the property, creating an attribute in the domain class, and storing a query result related to the attribute in the corresponding class; .
The method of claim 8,
Inheritance relationship designation for the relationship among the generated type,
Finding a pair of classes that have a parent-child relationship, if there is an object type corresponding to the pair of classes, registering the name of the parent object type with the child object type, and registering the name of the child object type with the parent object type. A method of transforming entity relationships in SPARQL query results for characterized RDF data.
The method of claim 8,
Correspondence number designation to determine the correspondence number,
Specifying a function and inverse function limit for the properties;
Retrieving a constraint of an object type and a constraint of a given relationship (ie, a user-defined property) and a range object type of the relationship for each object type (ie, a class);
And determining a corresponding number of properties by retrieving a corresponding restriction, a function, and an inverse function restriction for each relationship, wherein the entity relationship transformation method of the SPARQL query result for the RDF data.
The method of claim 8,
The entity type and relationship inheritance of the parent-child relationship,
Inheriting all information of the parent relationship to the child relationship and deleting the parent relationship;
Registering the inherited relationship with a domain entity type and storing information (query result) of the relationship;
Inheriting all information (relationships, properties, and query results) of the parent entity type to a child entity type, and then deleting the parent entity type, wherein the entity relationship transformation method of the SPARQL query result for RDF data is included. .
The method of claim 8,
Reducing the entity-relationship model
Initializing a variable of an object type used for model reduction;
Checking whether the entity type can be merged with another entity type by model reduction;
Calculating the number of relationships in which the entity type belongs to a range to determine the model reduction entity type;
And decompressing the model from the object type having the calculated relationship number of 0 and having a 1: 1 correspondence.
24. The method of claim 23,
If the connection between the entity type and the relationship forms a cycle, reconstructing the model from the entity type having a 1: 1 correspondence among the non-reduced entity types; How to transform the entity relationship of the result.
The method of claim 8,
The visualizing step,
Mapping an object storing a result of a variable indicated in a query condition among query results stored in each entity type, and generating a table for the entity;
Retrieving a relationship between the entity types for which the table is generated and generating a directional edge from a table corresponding to a domain entity type of a relationship to a table corresponding to a range entity type of a relationship;
After querying the query result stored in the object type in which the table is created, filling the query result corresponding to the variable of the query condition with the attribute value of the corresponding table, outputting the result and directional edges of tuples of different tables having the same tuple ID Method for transforming the entity relationship of the SPARQL query results for the RDF data comprising the step of connecting to.

Images