Warning:
This wiki has been archived and is now read-only.
View source for ISSUE-3: Graph Shape Association

Jump to: navigation, search
You do not have permission to edit this page, for the following reason:
The action you have requested is limited to users in one of the groups: Users, 106, 73865-chairs.
You can view and copy the source of this page.
This page is about the various ways to make connections between RDF graphs or portions of RDF graphs and constraints (or shapes) to be validated against that graph or portions thereof.  [http://www.w3.org/2014/data-shapes/track/issues/3 Issue 3] is concerned with this connection.

This page is not about how to select which part of the graph is to be validated against particular constraints or shapes.  (This latter is the subject of the separate wiki page showing how [[Resource Shape Association|nodes in an RDF graph are associated with shapes or constraints]].)

== Proposal ==

There are two ways of invoking a SHACL Engine.

In the first way there are two arguments.  One argument is for SHACL structures.  The other argument is for the data graph or dataset.  The engine then gets SHACL constructs from the SHACL argument and checks that the data graph or dataset is valid with respect to those constructs.  It is possible that the two arguments are the same, but there is no special processing in this case.  

In the second way there is only one argument, which is an RDF graph or dataset.  In the simple case, this RDF graph (or the default graph of the dataset) is used for SHACL structures and the graph or dataset is used as the data.  However, if the RDF graph (or default graph of the dataset) has a shacl pointer then the pointer is used to access an additional RDF graph which is merged with this graph to form the SHACL structures.  If there is a data pointer then the pointer is used to access an RDF graph or dataset with is used *instead* of this graph as the data graph.


This proposal handles the tricky cases where data is being returned from a service and other situations where there is a need to partly or wholely intertwine the SHACL constructs and the data.

A service could return an RDF graph that contains something like this:
:  The start node is X
:  The start shape is S
:  Look at <https:...> for the shape definitions and other SHACL stuff
:  ... data ... data .. data
To verify this claim a SHACL engine would run the shapes starting at the start node and the start shape against all the data in this graph.


A service could also return a small RDF graph that contains something like this:
:  Look at <https:...> for the scoped shapes
:  Look at <http:...> for the data
To verify this claim a SHACL engine would check that the data satisfies the scoped shapes.

Note that in the first service example that whatever encoding is used to specify the start node, start shape, and pointer to the other SHACL stuff ends up as part of the data that is being checked whereas in the second service example no SHACL-related informmation need show up in the data being checked.

== Different Ways of Associating Constraints or Shapes with RDF Graphs ==

=== Embedding ===

The simplest kind of connection is having the constraint or shape be part of the RDF graph.   These constraints or shapes would have to be identifiable as constraints or shapes and there would have to be indications on how they are to be validated.

So validating the graph available at <code>ex:graph</code> would look within this graph for sets of triples that encode a constraint or shape and validate them against the graph or portions thereof.

This kind of connection would be difficult in OWL constraints, because OWL constraints look just like OWL axioms.  SPIN can work this way, with the RDF graph including SPIN triples linking classes to constraints that are also in the graph.  ShEx does not appear to work this way.

=== Explicit Linking ===

Explicit links can be used to make connections from RDF graphs to documents containing constraints or shapes.  This is similar to <code>owl:imports</code>.  The RDF graph includes a triple whose object is the URL of a document containing constraints or shapes.  (There might be some other way to get from the object of the triple to the constraints or shapes, but using the normal web mechanisms is the most natural way.)  It is also possible to have an indirect link from the RDF graph to the constraints, i.e., the graph imports an ontology, which itself imports constraints or shapes.

So if an RDF graph containing data to be validated is available at <code>ex:data</code>, it would include a triple something like <code>ex:data shape:imports ex:constraints</code> and the document available at <code>ex:constraints</code> would include constraints or shapes to be validated against the graph.

OWL constraints can work this way, using a different explicit link from <code>owl:imports</code>.  SPIN uses <code>spin:imports</code> for this purpose.

[HK: I believe we need two properties, one for the traditional owl:imports and one that includes the constraints without running the actual tests over the union graph. The latter is important for performance reasons: you want to be able to run all tests on a single database, yet the constraint definitions should not be repeated in every database graph. (PFPS:  Agreed.  However, this document is not about how to run the constraints, just how to get to them.)  SPIN has spin:imports for that scenario.]

=== Implicit Linking ===

Implicit links can be used to make connections from RDF graphs to documents containing constraints or shapes.  This is similar to the "follow your nose" philosophy.  An IRI in the RDF graph can be turned into a URL which is a URL of a document containing constraints or shapes.  

So if an RDF graph containing data to be validated is available at <code>ex:data</code>, the validation process would look at all of the IRIs in the graph (e.g., <code>foaf:mbox</code> and <code>foaf:Person</code> and <code>ex1:Student</code> and <code>ex2:JohnSmith</code>), try to use them to retrieve documents that contain constraints or shapes (perhaps the documents available at <code>foaf:</code>, <code>ex1:</code>, and <code>ex2:</code>, and then validate the graph or portions of the graph against these constraints.

Just about any setup that does not need external control of the constraints or shapes can work this way.  OWL constraints and SPIN fall into this category.  ShEx probably doesn't, as it needs some notion of what shapes are supposed to be applied to.

=== No Linking ===

The constraint or shape validation mechanism itself could take multiple arguments, one of which is a set of constraints or shapes to be validated.

So if an RDF graph containing data to be validated is available at <code>ex:data</code> and some constraints or shapes are available at <code>ex:constraints</code>, the constraint validation mechanism could be called as <code>validate(ex1:data,ex2:constraints)</code>.

Any kind of constraint or shape system could be easily changed to work this way.
Return to ISSUE-3: Graph Shape Association.
Retrieved from "https://www.w3.org/2014/data-shapes/wiki/ISSUE-3:_Graph_Shape_Association"
View source for ISSUE-3: Graph Shape Association

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Navigation

extra links

Tools
