X

Oracle Spatial and Graph – technical tips, best practices, and news from the product team

Using RDF Knowledge Graphs in the Oracle Public Cloud (Part 3)

Matthew Perry
Consultant Member of Technical Staff

This is the third and final installment of the series "Using RDF Knowledge Graphs in the Oracle Public Cloud." In this blog post, we will complete the setup of our RDF triplestore in the Oracle Public Cloud by configuring a W3C-standard SPARQL endpoint. Click the links for previous posts in this series: part 1, part 2.

The W3C defines several standard REST APIs for querying and updating RDF data. You can read more about the standards here. Oracle RDF Semantic graph leverages Apache Jena Fuseki to provide an implementation of those interfaces. Oracle Support for Apache Jena provides a tight integration between Apache Jena and Oracle RDF Semantic Graph through Oracle-specific implementations of Apache Jena interfaces.

This blog post will show how to setup and run Apache Jena Fuseki on our DBCS instance. Fuseki can run as a standalone server or a Java web application. In this case, we will run Fuseki as a standalone server on our DBCS instance. You could also setup an Oracle Java Cloud Service instance and deploy the Fuseki Java web application into the included Web Logic Server instance.

The first step is to download the latest Oracle Support for Apache Jena from OTN. Open a web browser to our OTN downloads page. Choose Download Oracle Database 12c Release 12.1.0.2 Support for Apache Jena 3.1, Apache Jena Fuseki 2.4, and Protégé Desktop 5.0. Note that this download works with Oracle Database versions 12.1.0.2 and later, so it is compatible with our 18.1 DBCS instance.

After the download completes, transfer the downloaded Oracle Support for Apache Jena file to your DBCS instance. In this example, we copied the file to /home/oracle. Further instructions on how to copy files to/from a DBCS instance can be found in the DBCS user guide or in the detailed HOW-TO available at the end of this post.

Open an SSH connection to your DBCS instance as the oracle user. See the DBCS user guide for more information on how to make an SSH connection to a DBCS instance.

Create a directory named Jena in /home/oracle. Then move rdf_semantic_graph_support_for_12c_and_jena310_protege_5.0_2017_01_19.zip to the newly created Jena directory and unzip the file.

After the unzip command has finished, you will see several directories and a README file.

We will now configure Fuseki to access the LGD_SPORT semantic model that we created earlier. Change directory to /fuseki and edit the config-oracle.ttl file.

Change the following default <#oracle> dataset specification from

<#oracle> rdf:type oracle:Dataset;
    oracle:connection
    [ a oracle:OracleConnection ;
      oracle:jdbcURL "jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=orcl)))";
      oracle:User "rdfuser" ;
      oracle:Password "rdfuser"
    ];
    oracle:allGraphs [ oracle:firstModel "TEST_MODEL" ] .

to

<#oracle> rdf:type oracle:Dataset;
    oracle:connection
    [ a oracle:OracleConnection ;
      oracle:jdbcURL "jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=PDB1.uspm020.oraclecloud.internal)))";
      oracle:User "rdfuser" ;
      oracle:Password "rdfuser"
    ];
    oracle:allGraphs [ oracle:firstModel "LGD_SPORT" ] .

Note that SERVICE_NAME will be different depending on the settings for your particular DBCS instance.

Next, we will change the default shiro.ini configuration to allow non-localhost connections. First, we need to startup Fuseki to create a /run directory. Simply execute the following command in the current /fuseki directory.

./fuseki-server

Once you see the message that Fuseki has started on port 3030, kill the process with Ctrl-C.

Now the /run directory should be created. Change directory to /run and edit shiro.ini.

Replace

/$/** = localhostFilter

with

/$/server = anon
$/** = localhostFilter

Change directory back to /fuseki and start the Fuseki service by running the following command:

nohup ./fuseki-server --config config-oracle.ttl > fuseki_out.log &

Note that we are using nohup to prevent the Fuseki process from terminating if our connection is closed.

That’s it. A Fuseki SPARQL endpoint is now up and running on our DBCS instance.

Now that the Fuseki server is up and running on port 3030 of our DBCS instance, there are two options for connecting:

  1. Create an SSH tunnel to our DBCS instance for port 3030.

  2. Create an access rule to open up port 3030 of our DBCS instance to the public internet.

In this blog post, we will illustrate the first method using an SSH tunnel. See the detailed HOW-TO at the end of the post for instructions on the second option. Using an SSH tunnel allows us to securely access port 3030 on our DBCS instance without opening port 3030 to the public internet.

First, use PuTTY or a similar tool to create an SSH tunnel to forward port 3030 on your client computer to port 3030 on your DBCS instance. We are using PuTTY in this example, as shown below. Refer to the DBCS user guide for detailed instructions.

Click Open to open the SSH tunnel and then open a web browser to http://localhost:3030.

Click query to open the SPARQL query interface.

Click info to see all the available REST endpoints.

Now we have used an SSH tunnel to connect to the SPARQL endpoint running on our DBCS instance.

We can also use curl to directly test the SPARQL REST interface over the SSH tunnel. In this example, we are using a Cygwin terminal on a Windows client computer. The following curl command will send the SPARQL query in the file test_query.rq to the Fuseki endpoint running on our DBCS instance and print the result to stdout.

curl –X POST –data-binary "@test_quey.rq" –H "Content-Type: application/sparql-query" –H "Accept: application/sparql-results+json" "http://localhost:3030/sparql"

And we’re done! We have successfully accessed a W3C-standard SPARQL REST endpoint running on our DBCS instance.

This concludes the final post in our "Using RDF Knowledge Graphs in the Oracle Public Cloud" series. In the first post, we setup and configured Oracle Spatial and Graph – RDF Semantic Graph on an 18.1 DBCS instance. In the second post, we loaded some RDF data and used SQL Developer’s SPARQL query editor to run some example queries, and, in this final post, we setup a W3C-standard SPARQL endpoint on our DBCS instance to provide a REST interface for our triplestore.

Detailed steps for everything covered in this blog series are available in this HOW-TO.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.