Re: Can Shapes always be Classes?

Thank you for the details Holger, SPIN it is more clear now to me.

I would like to give input to this WG on how we deal this with RDFUnit in
case it is of interest.

RDFUnit does this the opposite way of SPIN. Instead of assigning
constraints to classes or properties, we decorate (associate)  constraints
with classes, properties, ontologies, vocabularies, RDF graphs or
This decoration (association) occurs either manually or automatically based
on what properties / classes the constraints reference.
@prefix rut: <> .
ConstraintA rut:references ex:ClassA, ex:ClassB
ConstraintB rut:references ex:propertyX, ex:propertyY, ex:propertyZ

We additionally define rut:source that links to a vocabulary, ontology, an
RDF graph or an application.
ConstraintC rut:source foaf
ConstraintD rut:source foaf, skos # when a constraint involves properties
from 2 ontologies
ConstraintE rut:source <> # when some constraints apply
to a specific RDF Graph
ConstraintF rut:source <> # We could even
associate a constraint to a specific application IRI

For validation we have 2 modes: automatic / manual
The user defines the RDF Graph he wants to validate (local file, remote
file, dereferencable IRI, RDFa, SPARQL Endpoint).
We try to identify all namespaces, classes and properties in the RDF Graph
and search for constraints that have a reference to these with rut:source
or rut:references

The user manually specifies a set of rut:source items he would like to use.

As a final step, we bundle all constraints in a rut:TestSuite. RDFUnit
validates the RDF graph against the rut:TestSuite that was generated based
on the user preferences.
Although not yet implemented in code, the user could directly provide a
rut:TestSuite in the validation process.

With this approach, we can store all constraints on a single RDF graph and
based on the validation requirements we can select different constraints
each time.

There are a few other things that happen behind the scenes here but will
not contribute to this specific thread.


On Fri, Nov 21, 2014 at 10:50 AM, Holger Knublauch <>

> On 11/21/2014 17:54, Dimitris Kontokostas wrote:
>> Hi Holger, I am trying to understand the SPIN discovery mechanism a
>> little better, sorry if you already answered this earlier but couldn't find
>> the answer.
>> I can imagine how it works in simple cases but where would you store the
>> following two constraints:
>> 1) a Person should never be a Place (owl disjoint classes)
> Assuming you want to use the triple
>     ex:Person owl:disjointWith ex:Place
> for that, then this constraint could be attached to owl:Class:
>     ?this owl:disjointWith ?other .
>     ?instance a ?this .
>     ?instance a ?other .
> }
> Since you are basically defining a meta-language (here: owl:disjointWith),
> I guess it makes sense to attach the constraint to the metaclass too.
> Alternatively, you could also attach it to rdfs:Resource.
>  2) whenever a resource has property x or/and property y then it should
>> have property z
> This depends on how you want to model this. We have a SPIN template in
> production that ensures that if an instance has a value for ?property then
> it must also have a value for ?otherProperty. This can be attached to the
> class where those properties occur, e.g. as
> ex:Person
>     spin:constraint [
>         a spl:ExistencePropertyPairConstraint ;
>         arg:property ex:firstName ;
>         arg:otherProperty ex:lastName
>     ]
> and the body of that template is
>     _:b0 a spin:ConstraintViolation .
>     _:b0 spin:violationRoot ?this .
>     _:b0 spin:violationPath ?property .
>     _:b0 rdfs:label ?message .
> }
>         ?this ?otherProperty ?someValue .
>     } .
>         ?this ?property ?object .
>     } .
>     BIND (CONCAT("Property must have a value because ", ?otherProperty, "
> has") AS ?message) .
> }
>> I assume it should be rdfs:Resource, owl:Thing or rdf:Property, right?
>> Is it up to the user to decide this and what happens if he chooses to
>> attach it in one of the mentioned class / property?
> Yes it's up to the user.
>  Does this work for all subclasses of the general classes? i.e. can he
>> attach a constraint to owl:ObjectProperty?
> Yes.
> Holger

Dimitris Kontokostas
Department of Computer Science, University of Leipzig
Research Group:

Received on Friday, 21 November 2014 10:30:11 UTC