Setting Up the SPARQL Service

7.2 Setting Up the SPARQL Service

This section explains how to set up a SPARQL web service endpoint by deploying the fuseki.war file in WebLogic Server.

Although there are several ways to deploy applications in WebLogic Server, this topic refers to the autodeploy option.

Note:

If you want to deploy Fuseki in Apache Tomcat instead of WebLogic Server, see Deploying Fuseki in Apache Tomcat.

Download and Install Oracle WebLogic Server 12c or later.
Ensure that you have Java 8 or later installed.
Set the FUSEKI_BASE parameter, which defines the location of the Fuseki configuration files. By default, this parameter is set to /etc/fuseki.

You can set this parameter to the the fuseki folder from downloaded OTN kit, which already contains the fuseki configuration files. See the Jena Fuseki documentation for more details: https://jena.apache.org/documentation/fuseki2/fuseki-layout.html

Configure an Oracle dataset in the fuseki configuration file: config.ttl

Before editing the Fuseki configuration file, create an RDF schema-private network (explained in Schema-Private RDF Networks). For example, assuming a network with name SAMPLE_NET in user schema RDFUSER and tablespace RDFTBS, the following command creates the RDF network.
```
EXECUTE SEM_APIS.CREATE_RDF_NETWORK('RDFTBS', options=>'MODEL_PARTITIONING=BY_HASH_P MODEL_PARTITIONS=16', network_owner=>'RDFUSER', network_name=>'SAMPLE_NET' );
```

Edit file config.ttl, and add an oracle:Dataset definition using a model named M_NAMED_GRAPHS. The following snippet shows the configuration. The oracle:allGraphs predicate denotes that the SPARQL service endpoint will serve queries using all graphs stored in the M_NAMED_GRAPHS model.

<#oracle> rdf:type oracle:Dataset;
oracle:connection
[ a oracle:OracleConnection ;
oracle:jdbcURL "jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<host>)(PORT=<port>))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=<service_name>)))";
oracle:User "RDFUSER"
oracle:Password "<password>"
];
oracle:allGraphs [ oracle:firstModel "M_NAMED_GRAPHS";    
                   oracle:networkOwner "RDFUSER"; 
                   oracle:networkName "SAMPLE_NET"] .

Link the oracle dataset in the service section of the Fuseki configuration file:

<#service> rdf:type fuseki:Service ;
    # URI of the dataset -- http://host:port/ds
    fuseki:name                     "oracle" ;

    # SPARQL query services e.g. http://host:port/ds/sparql?query=...
    fuseki:serviceQuery             "sparql" ;
    fuseki:serviceQuery             "query" ;
    # SPARQL Update service -- http://host:port/ds/update?request=...
    fuseki:serviceUpdate            "update" ;   # SPARQL query service -- /ds/update

    # Upload service -- http://host:port/ds/upload?graph=default or ?graph=URI or ?default
    # followed by a multipart body, each part being RDF syntax.
    # Syntax determined by the file name extension.
    fuseki:serviceUpload            "upload" ;   # Non-SPARQL upload service

    # SPARQL Graph store protocol (read and write)
    # GET, PUT, POST DELETE to http://host:port/ds/data?graph= or ?default=
    fuseki:serviceReadWriteGraphStore      "data" ;

    # A separate read-only graph store endpoint:
    fuseki:serviceReadGraphStore       "get" ;   # Graph store protocol (read only) -- /ds/get

    fuseki:dataset           <#oracle> ;
    .

The M_NAMED_GRAPHS model will be created automatically (if it does not already exist) upon the first SPARQL query request. You can add a few example triples and quads to test the named graph functions. For example, for a database before Release 19.3:

SQL> CONNECT username/password
SQL> INSERT INTO m_named_graphs_tpl VALUES(sdo_rdf_triple_s('m_named_graphs','<urn:s>','<urn:p>','<urn:o>'));
SQL> INSERT INTO m_named_graphs_tpl VALUES(sdo_rdf_triple_s('m_named_graphs:<urn:G1>','<urn:g1_s>','<urn:g1_p>','<urn:g1_o>'));
SQL> INSERT INTO m_named_graphs_tpl VALUES(sdo_rdf_triple_s('m_named_graphs:<urn:G2>','<urn:g2_s>','<urn:g2_p>','<urn:g2_o>'));
SQL> COMMIT;

Go to the autodeploy directory of WebLogic Server and copy files, as follows. (For information about automatically deploying applications in development domains, see: http://docs.oracle.com/cd/E24329_01/web.1211/e24443/autodeploy.htm)
```
cd <domain_name>/autodeploy
cp -rf  /tmp/jena_adapter/fuseki_web_app/fuseki.war  <domain_name>/autodeploy
```
In the preceding example, <domain_name> is the name of a WebLogic Server domain.

Note that while you can run a WebLogic Server domain in two different modes, development and production, only development mode allows you use the autodeploy feature.
Verify your deployment by using your Web browser to connect to a URL in the following format (assume that the Web application is deployed at port 7001): http://<hostname>:7001/fuseki

You should see a page titled Apache Jena Fuseki, and a list of datasets on the server. This example should show the /oracle dataset.
Execute the query by clicking on the Query button on the /oracle dataset and entering the following query:
```
SELECT ?g ?s ?p ?o
WHERE 
{ GRAPH ?g { ?s ?p ?o} }
```
The result should be an HTML table with four columns and two sets of result bindings.

Parent topic: RDF Graph Support for Apache Jena

7.2.1 Client Identifiers

For every database connection created or used by the support for Apache Jena, a client identifier is associated with the connection. The client identifier can be helpful, especially in a Real Application Cluster (Oracle RAC) environment, for isolating RDF Graph support for Apache Jena-related activities from other database activities when you are doing performance analysis and tuning.

By default, the client identifier assigned is JenaAdapter. However, you can specify a different value by setting the Java VM clientIdentifier property using the following format:

-Doracle.spatial.rdf.client.jena.clientIdentifier=<identificationString>

To start the tracing of only RDF Graph support for Apache Jena-related activities on the database side, you can use the DBMS_MONITOR.CLIENT_ID_TRACE_ENABLE procedure. For example:

SQL> EXECUTE DBMS_MONITOR.CLIENT_ID_TRACE_ENABLE('JenaAdapter', true, true);

Parent topic: Setting Up the SPARQL Service

7.2.2 Using OLTP Compression for Application Tables and Staging Tables

By default, the support for Apache Jena creates the application tables and any staging tables (the latter used for bulk loading, as explained in Bulk Loading Using RDF Graph Support for Apache Jena) using basic table compression with the following syntax:

CREATE TABLE .... (... column definitions ...) ... compress;

However, if you are licensed to use the Oracle Advanced Compression option no the database, you can set the following JVM property to turn on OLTP compression, which compresses data during all DML operations against the underlying application tables and staging tables:

-Doracle.spatial.rdf.client.jena.advancedCompression="compress for oltp"

Parent topic: Setting Up the SPARQL Service

7.2.3 N-Triples Encoding for Non-ASCII Characters

For any non-ASCII characters in the lexical representation of RDF resources, \uHHHH N-Triples encoding is used when the characters are inserted into the Oracle database. (For details about N-Triples encoding, see http://www.w3.org/TR/rdf-testcases/#ntrip_grammar.) Encoding of the constant resources in a SPARQL query is handled in a similar fashion.

Using \uHHHH N-Triples encoding enables support for international characters, such as a mix of Norwegian and Swedish characters, in the Oracle database even if a supported Unicode character set is not being used.

Parent topic: Setting Up the SPARQL Service