Mirror of the Rel4tion website/wiki source, view at <http://rel4tion.org>

Clone

HTTPS: git clone https://vervis.peers.community/repos/yEzqv

SSH: git clone USERNAME@vervis.peers.community:yEzqv

Branches

• master

Tags

named-graphs.mdwn

Purpose

Explain what named graphs are and how they are used in database software.

Content

So far, it was assumed that a single program process runs and manages a single semantic database. In practice, for example in relational databases, it is common to have several separate databases, all managed by a single program. The program may use many threads and manage different databases in different processes, but it has a single interface which takes queries for all the stored databases.

A similar concept exists for semantic databases: A single server can manage many different graphs, i.e. different groups of statements. There is no semantic difference between the graphs: They can refer to each other and link to each other as if they were a single large database. The only difference is that different databases may be stored as separate files in separate locations.

Ways to implement this feature may be:

• Add a component to each statement, which says to which graph the statement belongs
• Add statements of the form [statement] [belongsToGraph] [MyGraph]
• Make the database implementation support storage of separate graphs

The third option should be preferred, because otherwise the result is a property without any actual semantic meaning. The separation to databases has no meaning but the ability to store them on the disk separately and move or copy them independently of other databases, and make it easy to choose their location in the file system and even put them under version control.

It is possible to use separate programs for seperate graphs, and it’s probably better in some cases, but in general a single interface can serve clients of all graphs: then queries combining data from several graphs can be executed efficiently, without the overhead of inter-process communication and synchronization protocols.

It is important to note that the separation of the database into separate graphs has no semantic value at all, and even if it seems that some graphs are used only for specific types of content, it is only an implementation detail, and only exists outside the data itself. For example, assume there is a separate graph storing the file system details. In order to perform efficient queries and help the user find information, it is okay for a database to have a statement like this:

• [file-system-graph] [isA] [Graph]
• [file-system-graph] [hasTopic] [file-system]

Now the existence of this separate graph does have a meaning and a purpose, but the data inside the graph doesn’t “know” about it, e.g. a File resource doesn’t know it belongs to a graph specific to file system details. The separation into graphs serves only for physical organization of the data, and has no meaning to the data itself.