KR101380605B1 - A Hypergraph-based Storage Method for Managing RDF Version - Google Patents

Abstract

A hypergraph-based RDF version management method for storing and managing versions by configuring RDF data as a hypergraph, the method comprising: (a) receiving a plurality of RDF data given different versions, wherein the RDF data is at least one triple; Consisting of; (b) designating the triple as one node to construct a node set including all triples, and configuring all the RDF data into a trunk set, wherein one RDF data belongs to a triple as one element of the trunk set; Comprising a set of nodes corresponding to; (c) constructing one hypergraph including the node set and the edge set; And (d) storing the hypergraph as a bipartite graph.
By the hypergraph-based RDF version management method as described above, it is possible to reduce the space for storing the RDF data for each version, and to quickly generate a version of the RDF data.

Description

A Hypergraph-based Storage Method for Managing RDF Version}

The present invention relates to a hypergraph-based RDF version control method for managing the version by configuring the RDF data into a hypergraph.

The Resource Description Framework (RDF) was established by the World Wide Web Consortium (W3C) as a standard for expressing meta information of web resources. Because RDF has a simple data model, well-defined semantics, and demonstrable inference, many Web sites distribute their data using the RDF format [Ref. 1].

RDF data, however, changes over time [Ref. 2]. As the domain's own information (or real-world information) changes, so do the RDFs that model it. This is like changing information in the database. And it can change according to a user's request. In general, RDF data is developed in a distributed and collaborative environment by many users. Therefore, storing and managing RDF versions is very important for applications that use RDF data such as semantic web applications, linked open data, and e-commerce.

The main role of RDF version management is to store various RDF versions and to show the differences between them. Also, make sure that the user can easily access other versions.

Previous studies, such as SemVersion [3] and PromptDiff [4], focus only on how to access the various versions or how to find differences between them. However, previous methods do not consider storage space to support versions. The storage space and the creation time for creating a new version are one of the important considerations in a version control system.

In order to reduce the storage space, a change-based (Delta-based, DB) [5, 6] and a partial-relational-based method (Partial Order Index, POI) [7] have been proposed. However, these methods still have problems.

For example, the change-based method (DB) stores only one version and the part of the change between versions, not the version. Therefore, in order to create a version, you must execute a series of changes. The problem with this method is that the version creation time increases as the number of changes increases as the version increases.

On the other hand, partial-relationships (POIs) require less storage space than change based methods. In particular, if the newly created version is a super version or a sub version of the existing version, it takes up much less storage space. However, this method has a problem that cannot be applied in the general case where the newly created version simultaneously inserts and deletes (if the insert and delete occur at the same time, it breaks the partial relationship).

Next, the RDF data model will be described in more detail.

The RDF graph is a set of triples representing a binary relationship between two resources. Each triple is represented by a subject, a property or predicate, and an object [Ref. 1]. A resource (ie, a subject) is generally expressed as a Uniform Resource Identifier (URI), where the descriptor is the type of resource and the object is the value of the resource type for a particular subject. The value of the object can have a URI or a string called a literal.

The main RDF change is the insertion and deletion of triples [8]. Updates can be represented by delete and insert operations. In other words, deleting a triple and inserting a new triple is an update operation. In general, these operations are widely used in RDF version control. Thus, the RDF version RV _i consists of a triple set of subject, predicate and object words, expressed as t ∈ RV _i . T means triple.

Next, the conventional methods of storing the RDF data version will be described in more detail. That is, three storage methods for the RDF version will be described. Each technique is supposed to refer to all snapshots (AS), change based (DB), and partial-relational based (POI) [Refs. 3-7].

The snapshot (AS) method [3,4] stores each version in a separate, separate repository. This technique focuses on finding the differences between versions and query-response between versions. Since all versions are saved separately, you need to calculate each time to find the change between versions. In addition, these methods did not consider storage space. In other words, since the data is stored in an independent storage, the overlapping data is exponentially increased.

The change based (DB) method [Refs. 5, 6] stores only the changed parts and the editor operations (insert and delete operations) for them to build different versions. In general, this method saves the last version and the previous versions only save the changes. The specific version is created by inverting the editor operation. However, these methods are not efficient for generating versions. The more versions you have, the more changes you need to calculate, which requires operations like union and difference.

The partial-relational based (POI) method [7] focused on the storage space of repositories that support RDF versions. This method provides significant storage space benefits and provides an efficient version insertion algorithm. Because this storage method is based on a partial relationship of a triple set, you can only benefit if the new version is a higher or a lower subset. However, the new version cannot be a parent or a subset because the insert and delete occur at the same time. Also, to generate a specific version, this method has the disadvantage of searching all the parent nodes of a given node in the POI graph.

Klyne, G. and Carroll, J.J. Resource Description Framwork (RDF): concepts and abstract syntax. W3C Recommendation. http://www.w3c.org/TR/rdf-concepts. Flouris, G., Manakanatas, D., Kondylakis, H., Plexousakis D., and Antoniou, G. 2008. Ontology change: classification and survey. The Knowledge Engineering Review. 23, 2 (June, 2008), 117-152 Volkel, M. and Groza, G. 2006. SemVersion: An RDF-based ontology versioning system. In Proceedings of the 5th IADIS International Conference on WWW / Internet Noy, N. F. and Musen, M. A. 2004. Ontology versioning in an ontology management framework. IEEE Intelligent Systems. 19, 4 (July, 2004), 6-13 Tichy, W. F. 1985. RCS- a system for version control. Software Practice & Experience. 15, 7 (July, 1985), 637-654 Zeginiz, D., Tzitzikas, Y. and Christophides, V. 2007. On the foundation of computing deltas between RDF models. In Proceedings of 6th International Semantic Web Conference. Tzitzikas, Y., Theoharis, Y., and Andreou, D. 2008. On Storage Policies for Semantic Web Repositories that Support Versioning. In Proceedings of the 5th European Semantic Web Conference Ognyanov, D. and Kiryakov, A. 2002. Tracking changes in RDF (S) repositories. In Proceedings of International Conference on Knowledge Engineering and Knowledge Management. Berge, C. Graphs and Hypergraphs, North-Holland Publisher, Amsterdam, 1973. Wu, G., Li, J. and Wang., K. 2008. System Π: A hypergraph based native RDF repository. In Proceedings of WWW Conference

SUMMARY OF THE INVENTION An object of the present invention is to solve the problems described above, and to provide a hypergraph-based RDF version control method that can manage the version by configuring the RDF data as a hypergraph, showing efficient storage space and also faster version generation. It is.

In order to achieve the above object, the present invention relates to a hypergraph-based RDF version management method for managing a version by configuring the RDF data into a hypergraph, (a) receiving a plurality of RDF data given different versions, The RDF data consists of at least one triple; (b) designating the triple as one node to construct a node set including all triples, and configuring all the RDF data into a trunk set, wherein one RDF data belongs to a triple as one element of the trunk set; Comprising a set of nodes corresponding to; (c) constructing one hypergraph including the node set and the edge set; And (d) storing the hypergraph as a bipartite graph.

As described above, according to the hypergraph-based RDF version management method according to the present invention, it is possible to reduce the space for storing the RDF data for each version, and to quickly generate a version of the RDF data.

That is, the present invention finds and overcomes the problems of the existing version control system, one of which is storage space overhead and the other is computation time for creating a new version.

In addition, the present invention proposes a hypergraph-based storage method for the RDF version, that is, by using a hypergraph structure and including a node corresponding to the RDF triple by the hyperedge, the storage space by the hypergraph-based method It also reduces the cost and speeds up version creation.

In particular, through experiments, the present invention shows that the present invention is much superior to the conventional techniques such as snapshot (AS), change based (DB), and partial-relational based (POI). .

1 shows the configuration of an entire system for implementing the present invention.
2 shows an example of a hypergraph according to the present invention.
3 is a flowchart illustrating a hypergraph-based RDF version control method according to an embodiment of the present invention.
4 is an example of an RDF data version in accordance with the present invention.
5 is an example in which the RDF data according to the present invention is displayed in a hypergraph.
6 shows a comparison between the present invention and the prior art (partial-relationship based method).
7 illustrates a hypergraph presentation method according to the present invention.
8 shows an example of a class diagram and a relational database schema in accordance with the present invention.
9 shows an example of an optimization method according to the invention.
10 is a table showing the attributes of an actual data set according to an experiment of the present invention.
11 is a comparison graph of the present invention and the prior art for the storage space overhead according to an experiment of the present invention.
12 is a comparison graph of the present invention and the prior art for the version generation time according to an experiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, the present invention will be described in detail with reference to the drawings.

In the description of the present invention, the same parts are denoted by the same reference numerals, and repetitive description thereof will be omitted.

First, examples of the configuration of the entire system for carrying out the present invention will be described with reference to Fig.

As shown in FIG. 1A or 1B, the RDF version management method according to the present invention may be implemented as a computer program and installed in a server or a computer terminal device. That is, the entire system for practicing the present invention may be implemented as a server system on a network or a program system on a computer terminal. The system in which the RDF version management method according to the present invention is installed and executed in a computing device such as a server or a computer terminal will be referred to as an RDF version management system.

As shown in FIG. 1A, an example of an overall system for implementing the present invention is composed of a user terminal 10 and an RDF version management system 30 and connected to each other via a network 20. It is also possible to further include a database 40 for storing necessary data.

The user terminal 10 is a terminal that uploads RDF data to a server or management system 30 or receives and uses RDF data from the management system 30. The user terminal 10 may be used by a user such as a PC, a notebook computer, a netbook, a PDA, a mobile device, and the like. Computing terminal.

The RDF version management system 30 is connected to the network 20 as a conventional server to provide a service for storing and managing RDF data or versions of RDF data.

The database 40 is a conventional storage medium for storing data required by the RDF version management system 30, and stores RDF data and the like in a hypergraph form.

As shown in FIG. 1B, another example of the entire system for implementing the present invention is composed of an RDF version management system 30 in the form of a program installed in the computer terminal 13. That is, each function of the RDF version management system 30 is implemented as a computer program and installed in the computer terminal 13 so that the user 14 receives the RDF data or the RDF version data, etc. by the input device of the computer terminal 13. It receives the data stored in the storage device or the external storage device (including network storage device) of the computer terminal 13 or received. In addition, the RDF version management system 30 outputs the requested RDF version and the like through the output device of the computer terminal 13. Meanwhile, data necessary for the RDF version management system 30 is stored and used in a storage space such as a hard disk of the computer terminal 13.

Next, the hypergraph to be used in the present invention will be described in more detail with reference to FIG. 2.

Hypergraphs are a generalization of graphs, and edges can connect multiple nodes. According to Document 9, the hypergraph H = (V, E) and the node set V = {v ₁ , v ₂ ,... , v _n }, edge set E = {E ₁ , E ₂ ,.. , E _n }. In the hyper-edge, each edge E _j must have at least one V, and the union of all E _j is V. In general graph edges connect two nodes, whereas hyper edges connect two or more nodes. For example, FIG. 2 shows six nodes V = {v ₁ , v ₂ , v ₃ , v ₄ , v ₅ , v ₆ } and four hyperedges E = {E ₁ , E ₂ , E ₃ , E ₄ Show a hypergraph with}. If every hyper edge has K nodes, it is called K-uniform. A common graph is a 2-uniform hypergraph.

Next, a hypergraph-based RDF version management method according to an embodiment of the present invention will be described in more detail with reference to FIG. 3.

As shown in Figure 3, the hypergraph-based RDF version management method according to an embodiment of the present invention, (a) receiving the RDF data (S10); (b) organizing the RDF data into a node set and a trunk set (S20); (c) constructing the node set and the trunk set as a hypergraph (S30); (d) a step S40 of constructing the hypergraph into a bipartite graph. In addition, (e) optimizing the hypergraph (S50); Or (f) searching and returning according to the RDF data request (S60).

First, step S10 of receiving RDF data will be described.

That is, a plurality of RDF data given different versions are received (S10). The RDF data is composed of at least one triple.

One resource description framework (RDF) data is one version of data and is composed of at least one triple. The triple is represented by a subject, a property or predicate, and an object.

A subject (or resource) is generally expressed as a Uniform Resource Identifier (URI), where the descriptor is the type of resource (or subject) and the object means the value of the resource type for a particular subject. The value of the object can have a URI or a string called a literal.

In addition, version management of the RDF data may be performed by triple insert and delete operations. Updates can be represented by delete and insert operations. In other words, deleting a triple and inserting a new triple is an update operation. Thus, the RDF version RV _i consists of a triple set of subject, predicate and object words, expressed as t ∈ RV _i . T means triple.

An example of RDF data is shown in FIG. 4, four RDF data versions RV ₁ = {x, y}, RV ₂ = {x, y, z}, RV ₃ = {x, z}, and RV ₄ = {x, y, z}. x, y, and z represent triple (or triple ID).

Next, the triple is defined as one node to form a node set including all triples, and all the RDF data is configured as a trunk set (S20). At this time, one RDF data is composed of a set of nodes corresponding to a triple belonging to one of the trunk set.

In addition, since the edge set is a set, at least two RDF data having the same triple are set as one element.

In the above example, all triples included in the RDF data versions RV ₁ , RV ₂ , RV ₃ , and RV ₄ are x, y, z. Thus, the node set consists of {x, y, z}.

Since RV ₂ and RV ₄ have the same configuration as {x, y, z}, they are determined as one element of the trunk line set. Therefore, RV ₁ is defined as element E ₁ , RV ₂ and RV ₄ as element E ₂ , and RV ₃ as element E ₃ . That is, as in RV ₁ → E ₁ , the version ID is mapped to one hyper-edge.

Next, one hypergraph including the node set and the edge set is configured (S30).

In the above example, when expressed as a hypergraph including the node set and the edge set is represented by Equation 1.

[Equation 1]

V = {x, y, z},

E = {E ₁ , E ₂ , E ₃ } = {{x, y}, {x, y, z}, {x, z}}.

In addition, a hypergraph is shown in FIG. 5.

The present invention is a hypergraph-based version control method for RDF data. The basic idea of this method is: All RDF versions of RV can be represented in hypergraphs. Any RDF version RV _i is mapped to the hyper trunk and all nodes will contain RDF triples. Hypergraph-based methods are intuitive and very easy to understand.

For ease of understanding, Figure 6 shows a comparison of the conventional POI method and the method according to the present invention (hypergraph based, HB). Although the POI method has fewer triples than the present invention (HB method), POI requires edges between the furnaces. (RV ₂ ⊆ RV ₁ in FIG. 6). Therefore, POI needs extra space for storing POI graph information. In addition, in the hypergraph technique, x of FIG. 6 needs to be stored only once using an optimization method described below.

The present invention contemplates several versions. In addition, the hyper trunk of the present invention may include a plurality of nodes. Therefore, it is more flexible to consider the properties of the hypergraph.

Next, the hypergraph is implemented as a bipartite graph and stored (S40). Alternatively, the hypergraph is implemented by an incidence matrix instead of a bipartite graph and stored.

Hypergraphs can be represented by matrices. All hypergraphs H are represented by an m-by-n matrix A = (a _ij ) with m rows representing H's edges and n columns representing H's nodes.

That is, the matrix A = (a _ij ) can be expressed as Equation 2 below.

&Quot; (2) "

If the above example is represented by an incidence matrix according to [Equation 2], it is as shown in Figure 7a.

In another embodiment, the hypergraph H may be represented by a bipartite graph BG. The triple set of V and hyper-edge E represents a part of BG, respectively, and the edge (x, E ₁ ) of BG indicates that node x is included in hyper-edge E1. 7b shows a matrix and a double graph representation. Since the matrix method is only useful for dense graphs in the present invention, it is preferable to use the double graph method.

In particular, the hypergraph is modeled and stored as a class diagram. The class diagram is composed of a node class and a trunk class, the node class is composed of a node ID (ID) and a triple, and the trunk class is composed of a trunk ID (ID) and a version ID (ID).

In another embodiment, the hypergraph is modeled and stored in a relational database. The relational database is composed of a node table, a trunk table, a relationship table, the node table is composed of a node ID (ID) and a triple, the trunk table is composed of a trunk ID (ID) and a version ID (ID), The relationship table is composed of a node ID and a trunk ID.

8 shows a class diagram and a relational database schema of a hypergraph-based storage method in accordance with the present invention.

As shown in FIG. 8A, the class Vertex represents the node of the hypergraph H and has four fields (Id, Subject, Predicate, Object). The ID (Triple ID) is used to identify the node and the other fields represent triples. The hyper trunk class consists of two fields: ID and Version ID.

As shown in Figure 7b, according to the class diagram, the present invention uses three tables (Vertex, Hyperedge, Relationship) as a relational database.

This storage technique has two advantages. First, the storage space can be reduced. Since hyper-edges have the same triples, there is no need to store separate versions with the same triples. For example, in the previous example, RDF versions RV ₂ and RV ₄ have the same triple {x, y, z}. Therefore, these two versions do not need to be stored separately, they only have one hyper-edge. This eliminates the need to store duplicate triple IDs. Second, when creating a new version, you only need to access the hyper-edge to create that version.

Next, the hypergraph is optimized with the common node (S50).

That is, when at least two or more elements among the elements of the trunk set have at least two nodes in common, the nodes having the common node are created as one node (hereinafter referred to as common node), and the common node is added to the node set. And among the elements of the trunk set, nodes belonging to the common node are replaced with the common node.

While the DB technique (change-based method) according to the prior art focuses on the changed portion, the optimization technique according to the present invention focuses on the portion that does not change. In other words, we target triples that are common to all versions. In general, the change between two successive versions is small. As reported in [Reference 4], about 97.3% does not change. Based on these observations, we propose an optimization technique that can reduce storage space, including the advantages of the DB method and the method of the present invention.

9 shows an optimization method according to the invention.

In FIG. 9, E _all means a hyper trunk including a maximum common triple. As shown in Fig. 9, triple IDs d and e appear in all hyper-edges. In this optimization step (S50) it is connected to E _all . Therefore, the edge of the BG graph connected to the hyper edge can be reduced. If the optimization phase shows a version RV _i after E _'i is optimized version RV _i may be expressed as: [Equation 3].

&Quot; (3) "

This step is much more effective when the rate of change is very small or when certain triples are inserted and deleted repeatedly.

Next, search and return according to the RDF data request (S60). That is, when a specific version of the RDF data is requested, the elements of the edge set corresponding to the specific version are searched and triples belonging to the searched elements are returned.

Therefore, the present invention can extract and generate the requested RDF data version immediately by one operation.

In view of version generation, the present invention is analyzed by comparing with the conventional DB method and POI method. For clarity, it is assumed that all versions consist of a linear version model without branches. That is, it is assumed that one version can come from only one version.

First, consider creating a version of the DB method. Given the RDF version RV _i , if RV _{i + 1} is the current version and the change between the two versions is Δ _{i, i + 1} , then RV _{i + 1} is given by Equation 4 below.

&Quot; (4) "

The new version is created by a number of change operations (delete triple and insert triple). The DB technique is useful when the variation between the two versions is small.

However, as mentioned earlier, the DB technique has a weakness in that performance is degraded in executing changes. This is because, in order to access the latest version, changes must be applied continuously from the first version. The version RV _i, given, the changing part between the version _i RV and _{RV j Δ i, i + 1} , Δ i + 1, i + 2, Δ i + 2, i + 3, ... Let Δ _{j-1, j} . At this time, the version RV _j is calculated as in Equation 5 below.

&Quot; (5) "

Intuitively, we can see that the cost of versioning is affected by the increase or decrease in the number of changes.

Version generation using the POI method requires visiting all ancestor nodes of a given node in the POI graph and merging the triples in the ancestor nodes with the current node. The triples of version RV _i are called N _i and N _t1 , N _t2,. For example, if N _tj is triples of ancestor nodes, version RV _i is calculated as shown in [Equation 6].

&Quot; (6) "

The cost of creating a version therefore depends on the depth of the POI graph. If the depth is deeper, the versioning performance is degraded. Although using indexes (transitive indexes or labeling techniques) to speed up version creation, these methods also require additional storage space and computation time.

On the other hand, the hypergraph-based method according to the present invention does not need to search all or part of the data regardless of the data structure. Only by accessing the corresponding hyper-edges can you create your own version. As a result, the performance of version generation is very important and thus the method according to the invention can be regarded as generally applicable to any RDF version.

Next, the effects of the present invention will be described in more detail through performance evaluation.

The hypergraph based storage method according to the present invention is compared with other storage methods (AS, DB, POI). Since AS and DB do not have an index structure, they are stored directly in triple storage. Specifically, four methods are evaluated for storage space and version creation time.

First, the experimental environment for performance evaluation will be described.

All experiments were performed on an Intel Xeon CPU 3GHz PC with 16G memory. All storage techniques are implemented in the Java language, using the Rio parser as the RDF parser, and Oracle 11gR2 as the relational database. DBPedia Ontology was used for the experiment. 10 shows the attributes of the actual data set. The data set consists of six versions (version 3.2 to version 3.7). All versions are not higher or lower versions of previous versions.

Next, the storage space overhead according to the experimental results is compared.

11 shows the required storage space for each storage method. The storage space of each method means the disk space in which all versions are stored (in the DB method, the changed part is included, and in the POI and the HB (invention), the triple ID is included). In the DB method, version 3.2 was selected as the version to actually save. As expected, the present invention (HB) method performed the best (the least amount of disk space). Although the size of the data used in the experiment was small, the difference between the methods is expected to increase if the number of versions increases. We also examined the number of triple IDs stored in HB and POI. HB's triple ID sum was much smaller than POI. We also found that 1418 triple IDs remained unchanged during evolution. This could be reduced through the optimization method according to the invention.

Next, the version generation time according to the experimental results is compared.

12 shows version generation time of DB, POI, HB (invention). The y side shows the version creation time and the x side shows the version ID to be created. As shown in FIG. 12, it can be seen that the version generation time of the DB method increases in proportion to the number of versions. POI and HB can speed up version creation. However, the POI method must check for the presence of an ancestor node in the POI graph. Thus, the present invention (HB) shows better performance. If the edge of the POI increases, the performance of the POI will be further reduced.

Although the present invention has been described in detail with reference to the above embodiments, it is needless to say that the present invention is not limited to the above-described embodiments, and various modifications may be made without departing from the spirit of the present invention.

10: user terminal 13: computer terminal
14: User 20: Network
30: RDF Version Control System 40: Database

Claims (7)

In the hypergraph-based RDF version control method for managing the version by organizing the RDF data into a hypergraph,
(a) receiving a plurality of RDF data given different versions, wherein the RDF data is composed of at least one triple;
(b) designating the triple as one node to construct a node set including all triples, and configuring all the RDF data into a trunk set, wherein one RDF data belongs to a triple as one element of the trunk set; Comprising a set of nodes corresponding to;
(c) constructing one hypergraph including the node set and the edge set; And
(d) storing the hypergraph as a bipartite graph,
In the step (b), at least two RDF data having the same triple is determined by one element, hypergraph-based RDF version control method.
delete The method of claim 1,
In the step (d), the hypergraph is modeled and stored as a class diagram, wherein the class diagram is composed of a node class and an edge class, and the node class is composed of a node ID and triple, and the trunk class The hypergraph-based RDF version management method, characterized in that consisting of the edge ID (ID) and version ID (ID).
The method of claim 1,
In the step (d), the hypergraph is modeled and stored as a relational database, the relational database is composed of a node table, an edge table, a relation table, the node table is composed of a node ID (ID) and triple, The edge table is composed of a trunk ID (ID) and a version ID (ID), the relationship table is a hypergraph-based RDF version management method, characterized in that consisting of the trunk ID (ID).
The method of claim 1,
In the step (d), the hypergraph based RDF version control method, characterized in that for storing the hypergraph (incidence matrix) instead of a bipartite graph (bipartite graph).
The method of claim 1, wherein
(e) When at least two or more elements among the elements of the trunk set have at least two or more nodes in common, create nodes having in common as one node (hereinafter referred to as a common node) and add the common node to the node set. And replacing the nodes belonging to the common node among the elements of the trunk set with the common node.
The method of claim 1, wherein
(f) if requested for a specific version of RDF data, further comprising: searching for elements of the edge set corresponding to the specific version, and returning triples belonging to the searched elements; .

Images