6 Workspace Manager Support for RDF Data

6.1 Enabling Workspace Manager Support for RDF Data

Workspace Manager support for RDF data is not installed in the database by default. Instead, you must run a script named sdordfwm.sql after you enable semantic technologies support in the database (explained in Section A.1, "Enabling Semantic Technologies Support"). You only need to run sdordfwm.sql once for the database. To run this script, connect to the database as SYSDBA and enter the following statement as appropriate for your operating system:

• Linux: SQL> @$ORACLE_HOME/md/admin/sdordfwm.sql

• Windows: SQL> @%ORACLE_HOME%\md\admin\sdordfwm.sql

If you want to check whether Workspace Manager support is enabled for RDF data, enter the following query and see if the value returned is INSTALLED:

SELECT value FROM mdsys.rdf_parameter 
  WHERE namespace = 'COMPONENT' and attribute = 'RDFOWM';

6.2 Version-Enabling an RDF Model

To version-enable an RDF model, you version-enable its associated application table. For example, if an RDF model named contracts is associated with an application table named CONTRACTS_RDF_DATA, you can perform the version enabling as shown in the following example:

begin
  dbms_wm.enableVersioning (table_name => 'contracts_rdf_data'); 
end;
/

The application table must have a primary key, and you cannot specify the HISTORY or VALID TIME options.

The data stored in the application table and the corresponding RDF data in the semantic data store are versioned logically. The standard data manipulation operations (insert, update, delete) on a version-enabled application table maintain the version information for both the affected application table rows and the corresponding RDF triples in the semantic data store. Queries accessing the RDF data using the SEM_MATCH operator take the state of the active workspace and the relevant versions of data into account when constructing the result set.

You cannot use continually refreshed workspaces and multiparent workspaces when working with RDF data. However, other workspace operations (such as creating new workspaces, creating savepoints, setting access modes, and refreshing and merging workspaces) proceed as you would expect.

You can use Workspace Manager locks on the application table rows to avoid conflicting data manipulation operations in concurrent workspaces. The conflicts in such cases are detected based on the primary keys for the locked rows, and they may not directly translate to any meaningful locks on the RDF data, such as a lock on a sub-graph or a node. (See Section 6.4 for best practices involving version-enabled RDF data.)

6.3 Inferring from Version-Enabled RDF Models

You can use an RDF model to create one or more entailments through inference using system-defined and user-defined rulebases. When such a model is version-enabled, the associated entailments that store the inferred data are also version-enabled.

However, unlike the RDF models, which are versioned logically, the entailments are versioned physically. Thus, a workspace with some unmerged changes to an RDF model may maintain a private version of the entailment, which duplicates all the inferred triples that may already exist in the entailment corresponding to the parent workspace. Figure 6-1 shows a physically versioned entailment where private copies of the index are maintained for workspaces W1 and W2, which are child workspaces of the LIVE workspace.

Figure 6-1 Physical Versioning of Entailment (Rules Index)

Description of "Figure 6-1 Physical Versioning of Entailment (Rules Index)"

A workspace created from a parent workspace with a valid entailment will share the entailment with its parent until some workspace-specific data manipulation operations occur on the corresponding models. The first data manipulation operation within a workspace creates a private copy of the entailment and marks it INVALID. Workspace-private versions of inference data can be rebuilt using the SEM_APIS.CREATE_ENTAILMENT procedure, as shown in the following example:

begin
  sem_apis.create_entailment(
            index_name_in   => 'contracts_rdfs',
            models_in       => SDO_RDF_Models('contracts'),
            rulebases_in    => SDO_RDF_Rulebases('RDFS')); 
end;
/

Any subsequent additions to the RDF model within the workspace will mark the entailment as INCOMPLETE, although you can return it to a VALID status using the SEM_APIS.CREATE_ENTAILMENT procedure. When a workspace is merged, the workspace-private entailment is dropped, and the corresponding index in the parent workspace is marked INVALID.

6.4 Merging and Refreshing Workspaces in Version-Enabled RDF Models

A workspace modifying data stored in a version-enabled RDF model may contain additional changes to other RDF models or relational tables. The semantics for the merging or refreshing relational data modified in a workspace remain unchanged. Similarly, the merging or refreshing of the application table is subject to conflict analysis based on the primary key defined in the application table. Triples added and deleted in concurrent workspaces are not flagged as conflicts unless they are associated with the same primary key in the application table. For example, a parent and a child workspace may assert the same triple with different primary keys, and during a workspace merge both the triples are accepted. You can avoid such conflicts by generating the application table primary keys from the triple components.

When you work with RDF data, the types of conflicts that must be flagged vary depending on the application requirements. The conflicts include physical conflicts that exist between two triples, and logical conflicts that exist in a graph to which the triples belong. For example, two concurrent workspaces asserting a triple that captures the value of a specific contract physically conflict with each other. Similarly, a workspace that assigned a new project to a department (with an appropriate triple) may logically conflict with other workspace that reduced the budget for the department.

You can avoid these conflicts by acquiring appropriate Workspace Manager locks on the application table rows using the DBMS_WM.lockRows subprogram. For example, while adding a new triple that describes a specific resource, the application logic may acquire row locks for all application table rows that describe the same resource; in this case, failure to acquire the lock indicates a conflict.

If business conflicts between concurrent workspaces can be manually detected and reconciled, you can use the <application table name>_DIFF Workspace Manager view to obtain a summary of all the changes in two workspaces. For a version-enabled application table named contracts_rdf_data, the query in following example fetches the triples for all the rows that are modified either in W2 workspace or the LIVE workspace:

begin
  dbms_wm.SetDiffVersions(workspace1 => 'W2',
                          workspace2 => 'LIVE');
end;
/
 
SELECT appt.apptable_pkey, appt.triple.get_triple() triple, 
       wm_diffver, wm_code FROM contracts_rdf_data_diff appt;

For an explanation of the possible values for the WM_DIFFVER and WM_CODE columns, see the section about xxx_DIFF views in Oracle Database Workspace Manager Developer's Guide.

For any conflicts detected using this technique, you can resolve them by executing compensating data manipulation operations for the conflicting data modifications.