Warning:
This wiki has been archived and is now read-only.

ISSUE-1: What inferencing can or must be used?

From RDF Data Shapes Working Group
Jump to: navigation, search

Introduction

RDF supports the notion of semantic extensions such as RDFS, OWL, and RIF (see RDF 1.1 Semantics, Semantic Extensions and Entailment Regimes). A semantic extension normally defines an Glossary#Entailment_Regime entailment regime. An entailment regime defines how additional triples are inferred from an explicitly given set of triples. An RDF application may rely on some semantic extension. Users of this type of application may not make a distinction between the explicit and inferred triples, nor may they even be aware that inferencing has taken place. This implies that we must consider the relation between constraint checking and semantic extensions in order to achieve a useful result for application users. For example, it would be confusing for a constraint to fail because an explicit triple was absent, but the same triple was inferred. A user viewing the inferred triples would be confused by the error message that said the triple was missing.

SPARQL

This issue occurs when querying RDF data. The SPARQL specification addresses through the explicit use of entailment regimes (see SPARQL 1.1 Entailment Regimes]. Conceptually, a SPARQL query is based on graph pattern matching, and the graph on which the patterns are matched is the graph the results from applying the entailment relation to the explicitly given triples.

There is a close connection between queries and constraint-checking. A constraint may be viewed as a query that returns TRUE if the constraint is satisfied and FALSE if the constraint is violated. This view of constraints is similar to the use of assertions in programming language. Equally, a constraint could be phrased a query that searched for violations, and return FALSE if no violations were found. When violations exist, a more complex query could return information about where or why the violations occur. This information could be used on an error message. SPARQL ASK queries could be used to check assertions or violations. SPARQL SELECT or CONSTRUCT queries could be used for error messages.

Since there is a significant and useful overlap between constraint-checking and SPARQL queries, one way forward is to adopt the approach that SPARQL uses for entailment regimes, possibly with additional semantics for how they are used for constraint-checking.

OSLC Resource Shapes

OSLC in general does not currently rely on any semantic extension. The semantics of OSLC Resource Shapes are not formally defined, but the assumption is that they refer to the explicitly given set of triples present in HTTP requests because an OSLC service is not expected to apply any inferencing to them. An OSLC service that stores triples in an information resource may add triples to that resource, e.g. for creator, creation date, etc., but these are not inferred triples. They are system generated triples.

SPIN

TDB.

ShEx

TDB.

OWL ICV

TDB.

DC Application Profiles

TDB.