6 Workspace Manager Support for RDF Data

RDF data stored in the Oracle Database semantic data store can be version-enabled using Oracle Database 11g Workspace Manager. Using Workspace Manager, you can create new versions of RDF data through data modification operations while maintaining a copy of the old data. For detailed usage and reference information about Workspace Manager, see Oracle Database Workspace Manager Developer's Guide.

The unit of versioning for the semantic data store is a model, which is in turn associated with an application table that resides in a user schema. Traditional Workspace Manager interfaces are used to manage a version-enabled RDF model. (However, you cannot use version-enabling on a model that participates in a virtual model. Virtual models are described in Section 1.3.8)

Creating the first version-enabled RDF model in a database re-creates an index on the underlying triple store that holds data for all RDF models. Thus, the time needed to create the first version-enabled RDF model depends on the amount of existing data in these models.

This chapter discuss the key characteristics of a version-enabled RDF model and provides some examples. It contains the following major sections:

Section 6.1, "Enabling Workspace Manager Support for RDF Data"
Section 6.2, "Version-Enabling an RDF Model"
Section 6.3, "Inferring from Version-Enabled RDF Models"
Section 6.4, "Merging and Refreshing Workspaces in Version-Enabled RDF Models"
Section 6.5, "Special Considerations When Using Workspace Manager Support for RDF Data"
Section 6.6, "Usage Flow Example: Versioning Semantic Models"

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.1.1 Removing Workspace Manager Support for RDF Data

After you have enabled Workspace Manager support for RDF data, you might need to remove that support in certain circumstances. For example, before you downgrade or remove semantic technologies support in the database, you must remove the Workspace Manager support for RDF data. (For information about downgrading and removing semantic technologies support, see Appendix A, "Enabling, Downgrading, or Removing Semantic Technologies Support".)

To remove Workspace Manager support for RDF data, perform the following steps:

Connect to the database as the SYS user with SYSDBA privileges (SYS AS SYSDBA, and enter the SYS account password when prompted).
Start SQL*Plus, and enter the following statement:
- Linux: @$ORACLE_HOME/md/admin/sdordfwm_rm.sql
- Windows: @%ORACLE_HOME%\md\admin\sdordfwm_rm.sql

After the sdordfwm_rm.sql script completes successfully, you can downgrade or remove semantic technologies support in the database.

6.2 Version-Enabling an RDF Model

To version-enable an RDF model, you must create any necessary entailments (rules indexes) on it (using the SEM_APIS.CREATE_ENTAILMENT procedure), and then 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.

6.5 Special Considerations When Using Workspace Manager Support for RDF Data

Certain Semantic Technologies features are not compatible with Workspace Manager for RDF data.

The following network-level features are not supported on semantic networks containing version-enabled RDF models:

Oracle Label Security (OLS) for RDF data
Virtual Private Database (VPD) for RDF data
Semantic indexing for documents
SEM_APIS.DROP_SEM_NETWORK with the cascade option

The following model-level features are not supported on version-enabled RDF models:

6.6 Usage Flow Example: Versioning Semantic Models

Example 6-1 shows how entailments can be handled in different workspaces. Comments within the example explain the individual operations.

Note the following restrictions and considerations for version-enabled RDF models, which are reflected in Example 6-1:

Incremental inference is not supported for entailments involving version-enabled RDF models.
Although an already created entailment can be made VALID by calling SEM_APIS.CREATE_ENTAILMENT, a new entailment cannot be created once the application table corresponding to an RDF model has been version-enabled.
The pattern argument for SEM_MATCH needs to use the old (non-curly-brace) syntax.
The following option must be used in the SEM_APIS.CREATE_ENTAILMENT invocation involving version-enabled models: 'EPT=1' (or options => 'USER_RULES=T,EPT=1' when user-defined rules are used) .

Example 6-1 Versioning a Semantic Model

set pagesize 10000
 
-- 1. Enabling Workspace Manager Support for RDF Data
conn / as sysdba
@?/md/admin/sdordfwm.sql
 
set echo on
column x format a10
column y format a10
 
column owner format a10
column index_name format a12
column index_view_name format a18
column status format a10
 
-- create sem network and a test user
exec sem_apis.create_sem_network('SYSAUX');
grant connect,resource,unlimited tablespace to rdfuser identified by rdfuser;
 
-- 2. Create table and model: then Insert triples (that will lead to some inferred triples, when entailed)
 
conn rdfuser/rdfuser
 
CREATE TABLE emp_rdf_data(id number,triple sdo_rdf_triple_s);
ALTER TABLE emp_rdf_data add CONSTRAINT emp_rdf_data_PK PRIMARY KEY (ID);
 
EXEC SEM_APIS.CREATE_SEM_MODEL('emp0','emp_rdf_data','triple');
 
insert into emp_rdf_data values (0.1, sdo_rdf_triple_s('emp0','<Man>','rdfs:subClassOf','<Person>'));
insert into emp_rdf_data values (0.2, sdo_rdf_triple_s('emp0','<Woman>','rdfs:subClassOf','<Person>'));
insert into emp_rdf_data values (1, sdo_rdf_triple_s('emp0','<John>','rdf:type','<Man>'));
 
-- 3. Create entailments: one with user-def rules only and the other with OWL
 
exec sdo_rdf_inference.create_rulebase('family_rb');
 
insert into mdsys.rdfr_family_rb values (
'R1',
'(?x rdf:type <Man>)',
NULL,
'(?x rdf:type <Male>)',
NULL);
 
insert into mdsys.rdfr_family_rb values (
'R2',
'(?x rdf:type <Woman>)',
NULL,
'(?x rdf:type <Female>)',
NULL);
 
begin
sem_apis.create_entailment(
index_name_in => 'emp0_u_idx',
models_in => SDO_RDF_Models('emp0'),
rulebases_in => SDO_RDF_Rulebases('family_rb'),
options => 'USER_RULES=T,EPT=1');
end;
/
 
begin
sem_apis.create_entailment(
index_name_in => 'emp0_idx',
models_in => SDO_RDF_Models('emp0'),
rulebases_in => SDO_RDF_Rulebases('owlprime'),
options => 'EPT=1');
end;
/
 
select * from mdsys.rdf_rules_index_info;
select count(*) from mdsys.rdfi_emp0_u_idx;
select x,y from TABLE(SEM_MATCH('(?x rdf:type ?y)',sem_models('emp0'),sem_rulebases('family_rb'),null,null)) order by 1,2;
select count(*) from mdsys.rdfi_emp0_idx;
select x from TABLE(SEM_MATCH('(?x rdf:type <Person>)',sem_models('emp0'),sem_rulebases('OWLPRIME'),null,null)) order by 1;
 
-- 4. Activate versioning and re-try the queries
 
EXEC dbms_wm.enableVersioning (table_name => 'emp_rdf_data');
 
select * from mdsys.rdf_rules_index_info;
select count(*) from mdsys.rdfi_emp0_u_idx;
select x,y from TABLE(SEM_MATCH('(?x rdf:type ?y)',sem_models('emp0'),sem_rulebases('family_rb'),null,null)) order by 1,2;
select count(*) from mdsys.rdfi_emp0_idx;
select x from TABLE(SEM_MATCH('(?x rdf:type <Person>)',sem_models('emp0'),sem_rulebases('OWLPRIME'),null,null)) order by 1;
 
 
-- 4a. [fail] try to create a post-versioning entailment for testing
 
begin
sem_apis.create_entailment(
index_name_in => 'emp0_idx_2',
models_in => SDO_RDF_Models('emp0'),
rulebases_in => SDO_RDF_Rulebases('owl2rl'),
options => 'EPT=1');
end;
/
 
 
-- 5. Create Workspace and move into that workspace
 
exec dbms_wm.createworkspace('W1');
exec dbms_wm.gotoWorkspace('W1');
 
-- 5a. [fail] in this workspace, try to create a post-versioning entailment for testing
 
begin
sem_apis.create_entailment(
index_name_in => 'emp0_idx_3',
models_in => SDO_RDF_Models('emp0'),
rulebases_in => SDO_RDF_Rulebases('rdfs'),
options => 'EPT=1');
end;
/
 
-- 6. Workspace inherits the entailment from LIVE workspace (no physical copy yet)
 
select * from mdsys.rdf_rules_index_info;
select count(*) from mdsys.rdfi_emp0_u_idx;
select x,y from TABLE(SEM_MATCH('(?x rdf:type ?y)',sem_models('emp0'),sem_rulebases('family_rb'),null,null)) order by 1,2;
select count(*) from mdsys.rdfi_emp0_idx;
select x from TABLE(SEM_MATCH('(?x rdf:type <Person>)',sem_models('emp0'),sem_rulebases('OWLPRIME'),null,null)) order by 1;
 
-- 7. Insert some triples => causes LIVE entailments to be copied to this workspace and marked INVALID here
insert into emp_rdf_data values (2.1, sdo_rdf_triple_s('emp0','<Mary>','rdf:type','<Woman>'));
commit;
 
select * from mdsys.rdf_rules_index_info;
select count(*) from mdsys.rdfi_emp0_u_idx;
select x,y from TABLE(SEM_MATCH('(?x rdf:type ?y)',sem_models('emp0'),sem_rulebases('family_rb'),null,null)) order by 1,2;
select count(*) from mdsys.rdfi_emp0_idx;
select x from TABLE(SEM_MATCH('(?x rdf:type <Person>)',sem_models('emp0'),sem_rulebases('OWLPRIME'),null,null)) order by 1;
 
-- 8. Go back to LIVE workspace to confirm that the LIVE entailments are still VALID
 
disconnect
connect rdfuser/rdfuser
select * from mdsys.rdf_rules_index_info;
select count(*) from mdsys.rdfi_emp0_u_idx;
select x,y from TABLE(SEM_MATCH('(?x rdf:type ?y)',sem_models('emp0'),sem_rulebases('family_rb'),null,null)) order by 1,2;
select count(*) from mdsys.rdfi_emp0_idx;
select x from TABLE(SEM_MATCH('(?x rdf:type <Person>)',sem_models('emp0'),sem_rulebases('OWLPRIME'),null,null)) order by 1;
 
-- 9. Back to new workspace: make its entailments VALID
 
exec dbms_wm.gotoWorkspace('W1');
 
begin
sem_apis.create_entailment(
index_name_in => 'emp0_u_idx',
models_in => SDO_RDF_Models('emp0'),
rulebases_in => SDO_RDF_Rulebases('family_rb'),
options => 'USER_RULES=T,EPT=1');
end;
/
 
begin
sem_apis.create_entailment(
index_name_in => 'emp0_idx',
models_in => SDO_RDF_Models('emp0'),
rulebases_in => SDO_RDF_Rulebases('owlprime'),
options => 'EPT=1');
end;
/
 
select * from mdsys.rdf_rules_index_info;
select count(*) from mdsys.rdfi_emp0_u_idx;
select x,y from TABLE(SEM_MATCH('(?x rdf:type ?y)',sem_models('emp0'),sem_rulebases('family_rb'),null,null)) order by 1,2;
select count(*) from mdsys.rdfi_emp0_idx;
select x from TABLE(SEM_MATCH('(?x rdf:type <Person>)',sem_models('emp0'),sem_rulebases('OWLPRIME'),null,null)) order by 1;
 
-- 10. Go back to LIVE workspace to confirm that the entailments there are still VALID
 
disconnect
connect rdfuser/rdfuser
select * from mdsys.rdf_rules_index_info;
select count(*) from mdsys.rdfi_emp0_u_idx;
select x,y from TABLE(SEM_MATCH('(?x rdf:type ?y)',sem_models('emp0'),sem_rulebases('family_rb'),null,null)) order by 1,2;
select count(*) from mdsys.rdfi_emp0_idx;
select x from TABLE(SEM_MATCH('(?x rdf:type <Person>)',sem_models('emp0'),sem_rulebases('OWLPRIME'),null,null)) order by 1;
 
-- 11. Insert a new row into LIVE model => causes LIVE entailments to become INVALID
 
insert into emp_rdf_data values (3, sdo_rdf_triple_s('emp0','<Gary>','rdf:type','<Man>'));
commit;
 
select * from mdsys.rdf_rules_index_info;
select count(*) from mdsys.rdfi_emp0_u_idx;
select x,y from TABLE(SEM_MATCH('(?x rdf:type ?y)',sem_models('emp0'),sem_rulebases('family_rb'),null,null)) order by 1,2;
select count(*) from mdsys.rdfi_emp0_idx;
select x from TABLE(SEM_MATCH('(?x rdf:type <Person>)',sem_models('emp0'),sem_rulebases('OWLPRIME'),null,null)) order by 1;
 
-- 12. Back to new workspace: confirm that its entailment is still VALID
 
exec dbms_wm.gotoWorkspace('W1');
 
select * from mdsys.rdf_rules_index_info;
select count(*) from mdsys.rdfi_emp0_u_idx;
select x,y from TABLE(SEM_MATCH('(?x rdf:type ?y)',sem_models('emp0'),sem_rulebases('family_rb'),null,null)) order by 1,2;
select count(*) from mdsys.rdfi_emp0_idx;
select x from TABLE(SEM_MATCH('(?x rdf:type <Person>)',sem_models('emp0'),sem_rulebases('OWLPRIME'),null,null)) order by 1;
 
-- 13. Back to LIVE workspace: make the entailments VALID again
 
disconnect
connect rdfuser/rdfuser
 
begin
sem_apis.create_entailment(
index_name_in => 'emp0_u_idx',
models_in => SDO_RDF_Models('emp0'),
rulebases_in => SDO_RDF_Rulebases('family_rb'),
options => 'USER_RULES=T,EPT=1');
end;
/
 
begin
sem_apis.create_entailment(
index_name_in => 'emp0_idx',
models_in => SDO_RDF_Models('emp0'),
rulebases_in => SDO_RDF_Rulebases('owlprime'),
options => 'EPT=1');
end;
/
 
select * from mdsys.rdf_rules_index_info;
select count(*) from mdsys.rdfi_emp0_u_idx;
select x,y from TABLE(SEM_MATCH('(?x rdf:type ?y)',sem_models('emp0'),sem_rulebases('family_rb'),null,null)) order by 1,2;
select count(*) from mdsys.rdfi_emp0_idx;
select x from TABLE(SEM_MATCH('(?x rdf:type <Person>)',sem_models('emp0'),sem_rulebases('OWLPRIME'),null,null)) order by 1;
 
-- 14. Insert a new row into LIVE model => causes LIVE entailments to become INCOMPLETE
 
insert into emp_rdf_data values (4, sdo_rdf_triple_s('emp0','<Lory>','rdf:type','<Man>'));
commit;
 
select * from mdsys.rdf_rules_index_info;
select count(*) from mdsys.rdfi_emp0_u_idx;
select x,y from TABLE(SEM_MATCH('(?x rdf:type ?y)',sem_models('emp0'),sem_rulebases('family_rb'),null,null)) order by 1,2;
select count(*) from mdsys.rdfi_emp0_idx;
select x from TABLE(SEM_MATCH('(?x rdf:type <Person>)',sem_models('emp0'),sem_rulebases('OWLPRIME'),null,null)) order by 1;
 
-- 15. make the entailments in LIVE workspace VALID again
 
begin
sem_apis.create_entailment(
index_name_in => 'emp0_u_idx',
models_in => SDO_RDF_Models('emp0'),
rulebases_in => SDO_RDF_Rulebases('family_rb'),
options => 'USER_RULES=T,EPT=1');
end;
/
 
begin
sem_apis.create_entailment(
index_name_in => 'emp0_idx',
models_in => SDO_RDF_Models('emp0'),
rulebases_in => SDO_RDF_Rulebases('owlprime'),
options => 'EPT=1');
end;
/
 
select * from mdsys.rdf_rules_index_info;
select count(*) from mdsys.rdfi_emp0_u_idx;
select x,y from TABLE(SEM_MATCH('(?x rdf:type ?y)',sem_models('emp0'),sem_rulebases('family_rb'),null,null)) order by 1,2;
select count(*) from mdsys.rdfi_emp0_idx;
select x from TABLE(SEM_MATCH('(?x rdf:type <Person>)',sem_models('emp0'),sem_rulebases('OWLPRIME'),null,null)) order by 1;
 
-- 16. merge workspace: this should make the LIVE entailments INVALID
conn rdfuser/rdfuser
exec dbms_wm.mergeWorkspace('W1');
 
select * from mdsys.rdf_rules_index_info;
select count(*) from mdsys.rdfi_emp0_u_idx;
select x,y from TABLE(SEM_MATCH('(?x rdf:type ?y)',sem_models('emp0'),sem_rulebases('family_rb'),null,null)) order by 1,2;
select count(*) from mdsys.rdfi_emp0_idx;
select x from TABLE(SEM_MATCH('(?x rdf:type <Person>)',sem_models('emp0'),sem_rulebases('OWLPRIME'),null,null)) order by 1;
 
-- 17. remove workspace
exec dbms_wm.removeWorkspace('W1');
 
-- 18. disable versioning, refresh the INVALID entailments to make them VALID, and then query
exec dbms_wm.disableVersioning('emp_rdf_data');
 
select * from mdsys.rdf_rules_index_info;
select count(*) from mdsys.rdfi_emp0_u_idx;
select x,y from TABLE(SEM_MATCH('(?x rdf:type ?y)',sem_models('emp0'),sem_rulebases('family_rb'),null,null)) order by 1,2;
select count(*) from mdsys.rdfi_emp0_idx;
select x from TABLE(SEM_MATCH('(?x rdf:type <Person>)',sem_models('emp0'),sem_rulebases('OWLPRIME'),null,null)) order by 1;
 
begin
sem_apis.create_entailment(
index_name_in => 'emp0_u_idx',
models_in => SDO_RDF_Models('emp0'),
rulebases_in => SDO_RDF_Rulebases('family_rb'),
options => 'USER_RULES=T,EPT=1');
end;
/
 
begin
sem_apis.create_entailment(
index_name_in => 'emp0_idx',
models_in => SDO_RDF_Models('emp0'),
rulebases_in => SDO_RDF_Rulebases('owlprime'),
options => 'EPT=1');
end;
/
 
select * from mdsys.rdf_rules_index_info;
select count(*) from mdsys.rdfi_emp0_u_idx;
select x,y from TABLE(SEM_MATCH('(?x rdf:type ?y)',sem_models('emp0'),sem_rulebases('family_rb'),null,null)) order by 1,2;
select count(*) from mdsys.rdfi_emp0_idx;
select x from TABLE(SEM_MATCH('(?x rdf:type <Person>)',sem_models('emp0'),sem_rulebases('OWLPRIME'),null,null)) order by 1;
 
-- cleanup
exec sem_apis.drop_entailment('EMP0_IDX');
exec sem_apis.drop_entailment('EMP0_U_IDX');
exec sem_apis.drop_sem_model('EMP0');
exec sem_apis.drop_rulebase('FAMILY_RB');
drop table emp_rdf_data;
conn / as sysdba
drop user rdfuser cascade;