This preface contains:
The following are changes in Oracle Spatial and Graph RDF Semantic Graph Developer's Guide for Oracle Database 12c Release 1 (12.1.0.2).
SEM_MATCH supports SPARQL 1.1 Federated Query. The SERVICE construct can be used to retrieve results from a specified SPARQL endpoint URL. With this capability, you can combine local RDF data (native RDF data or RDF views of relational data) with other, possibly remote, RDF data served by a W3C standards-compliant SPARQL endpoint.
For information about support for SPARQL 1.1 Federated Query, see Section 1.6.8.
A new section (Section 10.4) explains how you can combine native triple data with virtual RDB2RDF triple data in a single SEM_MATCH query by means of the SERVICE keyword.
The following are changes in Oracle Spatial and Graph RDF Semantic Graph Developer's Guide for Oracle Database 12c Release 1 (12.1.0.1).
The following features are new in this release:
SEM_MATCH supports the following SPARQL 1.1 constructs, as explained in Section 1.6.7, "Graph Patterns: Support for SPARQL 1.1 Constructs":
An expanded set of functions
Virtual models can now be created with arbitrary combinations of models and/or entailments, as explained in Section 1.3.8, "Virtual Models". Previously, virtual models were required to have at least one model and were limited to at most one entailment.
Virtual models can now be replaced without first being dropped. A new REPLACE=T option for the SEM_APIS.CREATE_VIRTUAL_MODEL procedure lets you maintain access privileges for a virtual model while changing its definition. (The REPLACE=T option is analogous to using CREATE OR REPLACE VIEW with a view.)
New RDF Semantic Graph extension architectures enable the addition of user-defined capabilities:
The inference extension architecture enables you to add user-defined inferencing to the presupplied inferencing support.
The query extension architecture enables you to add user-defined functions and aggregates to be used in SPARQL queries, both through the SEM_MATCH table function and through the support for Apache Jena and OpenRDF Sesame.
For information about these features, see Chapter 9, "User-Defined Inferencing and Querying".
The OWL 2 EL profile is supported by the addition of the system-defined rulebase OWL2EL, as explained in Section 2.1.2, "Supported OWL Subsets".
The OGC GeoSPARQL standard for representing and querying spatial data is now supported, as explained in Section 1.6.11.1, "OGC GeoSPARQL Support".
Ladder-based inference is available as a convenient option for fine-grained triple-level security, as explained in Section 5.1.1, "Fine-Grained Security for Inferred Data and Ladder-Based Inference (LBI)".
You can create and use RDF views over relational data. Mapping relational data to RDF triples enables you to perform semantic operations conveniently, and without having to store RDF triples corresponding to the relational data. For information, see Chapter 10, "RDF Views: Relational Data as RDF".
Effective with Oracle Database Release 12.1, you can export and import a semantic network using the full database export and import features of the Oracle Data Pump utility, as explained in Section 1.7.5, "Exporting or Importing a Semantic Network Using Oracle Data Pump".
Support for the following in RDF Semantic Graph is deprecated in this release, and may be desupported in a future release:
Virtual Private Database (VPD) (see Appendix C, "Virtual Private Database Support in RDF Semantic Graph")
Version-enabled models (see Chapter 6, "Workspace Manager Support for RDF Data")
Some features previously described in this document are desupported in Oracle Database 12c Release 1 (12.1). See Oracle Database Upgrade Guide for a list of desupported features.
RDF Semantic Graph support for Apache Jena supports Apache Jena 2.7.2, including jena-arq-2.9.2 and jena-core-2.7.2. This support includes the following features:
Support for Retrieving User-Friendly Java Objects from SEM_MATCH or SQL-Based Query Results
Protege Plugin for Oracle Database and Oracle NoSQL Database Enterprise Edition Release 2.0.39
Support for SPARQL Queries with Translated SQL Text Larger Than 29000 Bytes
Java APIs for Managing the Table Responsible for Terminating Long-Running SPARQL Queries
For information about using the support for Apache Jena, see Chapter 7.
With support retrieving user-friendly Java objects from SEM_MATCH or SQL-based graph query results, you no longer need to parse and understand the subtle details embedded in projected columns like $RDFVTYP, $RDFLTYP, $RDFLANG, and $RDFCLOB; or their corresponding columns in MDSYS.RDF_VALUE$ including VALUE_TYPE, LITERAL_TYPE, LANGUAGE_TYPE, LONG_VALUE, and VALUE_NAME.
For an explanation and examples, see Section 7.5, "Retrieving User-Friendly Java Objects from SEM_MATCH or SQL-Based Query Results".
This plugin allows an easy integration of the Protege 4.1 visual ontology editing functions with the robust semantic data management capabilities provided by Oracle Database and Oracle NoSQL Database.
The plugin .jar file and installation document are under the protege_plugin/ directory of the release zip file.
In previous releases, a fixed data source name OracleSemDS was required in the Joseki deployment. This release allows you to customize the data source name through the oracle:dataSourceName setting in the Joseki configuration.
You can also customize the data source name used for establishing database connections to terminate long-running SPARQL queries using query ID (see Section 7.2.3, "Terminating Long-Running SPARQL Queries" for details). To change the default data source name, edit the following JVM property:
-Doracle.spatial.rdf.client.jena.dsNameForQueryMgt=OracleSemDS
The S2S feature has been enhanced such that it now supports very long SPARQL queries that have translated SQL texts that are hundreds of thousands of bytes long. However, Oracle still recommends the use of simpler (and shorter) SPARQL queries whenever possible, because simpler SPARQL queries are easier for users and application developers to understand, and they tend to be more efficient for Oracle Database to execute.
The Joseki web service endpoint can now work with an Oracle Database opened in read-only mode. Queries can be answered without problems.
S2S must be used for queries to work with a read-only Oracle Database.
This release reduces the amount of Joseki logging output. You can, however, set the trace level to 1 or higher to get more trace output for debugging purpose. For example:
-Doracle.spatial.rdf.client.jena.josekiTraceLevel=1
When a request to terminate a SPARQL query is sent using the following servlet:
http://<hostname>:7001/joseki/querymgt?abortqid=8761
the request (query ID and a timestamp) is recorded in a table named ORACLE_ORARDF_QUERY_MGT_TAB in user's schema.
The following methods have been added to the class oracle.spatial.rdf.client.jena.OracleQueryProgressMonitor to allow users to query, add, and remove entries in the ORACLE_ORARDF_QUERY_MGT_TAB table. Details of these methods are explained in the Javadoc (javadoc.zip is under the javadoc/ directory of the release zip file):
addQuery deleteAllQueries deleteQuery listQueries
Support is provided for Joseki deployment in Apache Tomcat and JBoss, in addition to Oracle WebLogic Server. For information, see Section 7.18, "Deploying Joseki in Apache Tomcat or JBoss".