Copyright (c) 2005 - 2017 Franz, Incorporated

Last updated 10 January 2017 at 15:42

• Documentation Index
  • Release Notes
  • Quick Start
  • Introduction
  • Setup and Configuration
    • Download
    • Server Installation
    • Server Configuration and Control
    • WebView
    • Database Upgrading
  • Server Management
    • Performance Tuning
    • Deleting Duplicate Triples
    • Purging Deleted Triples
    • Auditing
    • Replication
    • Point-in-Time Recovery
    • Transaction Log Archiving
    • Security Overview
    • Security Implementation
  • Tools
    • Data Loading
    • Data Export
    • Backup and Restore
    • Querying
    • RDFS++
    • Materializer
  • Details
    • AllegroGraph Indices
    • Full-text Indices
    • Encoded IDs
    • Connection Pooling
    • N-dimensional Geospatial Overview
    • 2-D Geospatial
    • Temporal
    • Social Network
    • JavaScript
    • Datatypes
    • Data Conversion (Rapper)
    • Stored Procedures
    • Triple Attributes
  • Querying
    • SPARQL documentation summary
    • SPARQL Reference
    • SPIN
    • SPARQL Magic Properties
    • Prolog
  • 3rd-party tools
    • Solr text Indices
    • MongoDB integration
    • Callimachus support
    • TopBraid Composer Plugin
    • Cloudera
  • Client APIs
    • Gruff
    • REST/HTTP interface
    • HTTP reference
    • Javadocs (Sesame and Jena)
    • Python API
    • Lisp Reference
    • JavaScript
  • Tutorials
    • N-dimensional Geospatial
    • SPARQL Tutorial
    • Java Sesame
    • Java Jena
    • Python Sesame
    • Lisp
    • Prolog
    • More...
  • Other
    • Suggested Reading
    • Conferences and Seminars
    • Source Code on Github
    • Community Resources
    • Amazon EC2
    • Copyrights
    • Change History
  • Franz, Inc.

Introduction

AllegroGraph has two different inference engines: one supports a superset of RDFS inference rules and the other supports OWL 2 RL. The first is called the dynamic RDFS++ reasoner because it generates inferred triples on-the-fly and does not save them in the triple-store. The second is an OWL 2 RL materializer: it uses a set of inference rules to generate new triples and adds them to the triple-store.

If the triple store is changed via additions or deletions then materialization may have to be run again so that the triple store contains the correct set of materialized triples.

The dynamic reasoner is best when:

• you do not need OWL 2 RL inference rules and
• the store you are using is changing.

The materializer is best when:

• OWL 2 RL inference is required or
• the store is relatively static.

OWL 2 RL is the subset of OWL 2 that is designed to support rule based reasoners. OWL 2 RL contains a large number of rules for generating triples and some rules for verifying that the triple store is consistent with respect to the OWL 2 RL ontology.

The materializer implements a subset of the OWL 2 RL rules and we plan to add more rules in future versions. The complete rule set is described on the OWL 2 RL reference page.

APIs

There is an AGWebView interface (see WebView, particularly the Repository Overview Page section), a Java interface (see AGMaterializer#newInstance() and AGRepositoryConnection#materialize), a Python interface, as well as the Lisp interface described below. There is also a command-line interface described next.

Command Line Interface

The program agmaterialize is the command-line version of the materializer. agmaterialize must be run on the same machine where the AllegroGraph server is running. Here is an overview of its options:

Usage:

agmaterialize [OPTIONS] DBNAME 

The options are identified with a double dash when the full option name is used (--verbose) and a single dash when a single letter abbreviation is used (-v).

Materialization options:

--delete

Delete existing materialized triples and exit. No materialization is performed.

--display-ontology

Read and display the store's ontology and exit. No materialization is performed.

-g GRAPH, --inferred-graph GRAPH

The graph into which inferred triples will be placed

--rule NAME

Specify materialization rule; can be used multiple times. Rules are: all, class, property, restriction, same-as, values-from.

--bulk

If specified, then materialization will be run in bulk mode. This mode provides approximately 30% faster materialization. Note that bulk mode is global to the store and means that transactions will not be durable (in particular, will not be logged). Therefore, the switch should generally be used only when the store is not being used for other operations and the store should be backed up when the materialization is complete.

Other options:

-v, --verbose : Include more output (this option may be repeated, the more times it appears, the more output will be provided).

Triple-store options:

-c CATALOG, --catalog CATALOG

CATALOG name on server; use "" for the root catalog. The default is the root catalog.

-p PORT, --port PORT

Server port (default 10035, which is the usual port default).

Example:

The database is lubm-50. The --catalog, --rule, and --verbose options are specified (--verbose twice which means more information will be provided than if --verbose was just specified once):

./agmaterialize -c stores --rule all --verbose -verbose lubm-50  

Lisp API

materialize-entailed-triples

The main function is

Examples

Examples of how to specify rulesets

(materialize-entailed-triples) 

will add the RDFS++ entailed triples.

(materialize-entailed-triples :with "all") 

will run all rules. Note that the result of this call may differ between versions of the materializer.

(materialize-entailed-triples :with  '("same-as" "restriction")) 

run the RDFS++ reasoning as well as "same-as" and "restriction".

(materialize-entailed-triples :with  '("values-from")) 

this is just basic RDFS++ reasoning as "restriction" was not specified as well so "values-from" is ignored.

(materialize-entailed-triples :without '("property"  "values-from")) 

run all rules except "property" and the "values-from" part of "restriction" reasoning.

The use-type-subproperty argument changes the triple which is generated in the following way:

Given:

classA rdfs:subClassOf classB  
mytype rdfs:subPropertyOf rdf:type  
objX   mytype          classA 

then:

we would normally generate this triple::

objX   rdf:type        classB 

but if use-type-subproperty is true then we will instead generate this triple:

objX   mytype          classB 

delete-materialized-triples

The second function in the API is:

Note: materialize-entailed-triples will call delete-materialized-triples before starting to add triples.

Rule Sets

The table below is from the OWL 2 RL definition. We’ve added a second column where we describe how this rule is treated by the materializer.

Rules which are not implemented are numbered 1, 2, or 3 or have no number at all. The numbers indicate why they aren’t done. The rules with no number have not been considered yet for inclusion in the materializer and may appear in a future version.

Rules numbered 10 or 11 have been included in the materializer. Rules numbered 10 are part of the basic RDFS++ materializer and always run. Rules numbered 11 are implemented by another part of the materializer where they are run as independent rules. If the number 11 is followed by one or more ruleset names then those rulesets must be enabled for these rules to run.

Key

Code	Explanation
1	Not done due to the database clutter that would result. May be an option in the future.
2	Not done because rule is a consistency check and does not materializes triples
3	Not done because it is too expensive to calculate a canonical value for each literal and compare that to the canonical value of every other literal to find those that are identical. Also this would add triples with a literal as the subject which is not valid RDF.
2	Not done but may appear in a future version of the materializer.
10	Done using initial RDFS++ code
11	Done via materialization rules