_{To be linked in with Advanced iTQL Operations.}

_{Note: This document will use the correct term of graph rather than the legacy term of model. This follows a similar change made some time ago by the W3C.}

Distributed Resolver¶

Since the URI describing a graph is usually a URL (ie. a Uniform Resource Locator), this provides TQL with sufficient information to find the graph to resolve a query against. By default, the Mulgara query engines will resolve the entire query against local resources. However, with the introduction of the Distributed Resolver, queries may nw be resolved against resources from multiple servers.

Remote Resolution¶

If a connection has been made to a given server, queries can be sent to that server which are to be resolved on a different server, simply by specifying the URL of the required graph. For instance, if a connection has been established to a server called myhost.mydomain, then the distributed resolver allows the following query to be resolved:

select $s $p $o
from <rmi://theirhost.theirdomain/server1#testdata>
where $s $p $o;

No special syntax is required to activate this resolver. Without the distributed resolver, this query will give an error, as the graph URL does not occur on the local server.

Multiple Servers¶

TQL has always permitted the use of multiple graphs in a query. The distributed resolver now permits those graphs to come from multiple servers. This allows Mulgara to resolve the following query:

select $s $p $o
from <rmi://localhost/server1#first> or <rmi://remotehost.domain/server1#second>
where $s $p $o;

This returns all data from graphs on either server.

Remote graph URLs may appear anywhere in a query, including an IN clause. The following query selects the names of people from a local graph and their email addresses from a remote graph:

select $name $mbox
from <rmi://localhost/server1#people>
where $person <rdf:type> <ns:Person>
  and $person <ns:hasName> $name
  and $person <ns:hasMbox> $mbox in <rmi://remotehost.domain/server1#mail>;

The use of remote graphs is as flexible as using local graphs. For instance, the last query may be selecting people from an intersection between two graphs, with the email addresses coming from a remote graph:

select $name $mbox
from <rmi://localhost/server1#people> and <rmi://secondhost.domain/server1#people>
where $person <rdf:type> <ns:Person>
  and $person <ns:hasName> $name
  and $person <ns:hasMbox> $mbox in <rmi://thirdhost.domain/server1#mail>;

Multiple Hosted Servers¶

Multiple servers may all be running on the same host. However, since a server typically requires access to unique system resources, these must be reconfigured before second and subsequent servers may be started.

To start a second service, the following must be modified:

• The network port for the Shutdown Hook on the server. This is set to 6890 by default. It is changed by setting a system definition for shutdownhook.port.
• The server name. The default for this name is server1. This is set with the -s switch on the command line.
• The HTTP server. A non-embedded Mulgara server will start an HTTP server to manage SOAP/HTTP requests and to serve documentation. By default this is set to 8080. This may be set with the -p switch on command line.
• The Name Service. Mulgara attempts to start a name service each time it starts, though only one of these can be run at a time. Turn off the creation of a new name service with the -n switch on the command line.

An example of starting a second server on a machine is shown here:

# java -Dshutdownhook.port=6892 -jar mulgara-1.1.0.jar -s server2 -p 8081 -n

Once this is done, the second server can be accessed in the same way as any remote server:

select $name $mbox
from <rmi://localhost/server1#people>
where $person <rdf:type> <ns:Person>
  and $person <ns:hasName> $name
  and $person <ns:hasMbox> $mbox in <rmi://localhost/server2#mail>;

Note that the mail graph is now on server2, and not server1.

Blank Nodes¶

Blank nodes from separate graphs are, by definition, always distinct. The string representation of blank nodes from other servers will always look different to the representation of local blank nodes.

Select/Insert¶

Insert-select queries may now be performed between graphs on different servers. Among other things, this provides an easy method of copying data between servers, as in this example:

insert
  select $s $p $o
  from <rmi://remotehost/server1#theirData>
  where $s $p $o
into <rmi://localhost/server1#mydata>;

This brings everything from the theirData graph into a local graph called mydata.

A more complex example could get a list of people from one server, find their properties on another server, and insert these details into a third server:

insert
  select $person $property $value
  from <rmi://localhost/server1#people>
  where $person <rdf:type> <ns:Person>
    and $person $property $value in <rmi://remotehost1/server1#properties>
into <rmi://remotehost2/server1#people>;