- From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Date: Fri, 21 Nov 2014 12:29:14 +0200
- To: Holger Knublauch <holger@topquadrant.com>
- Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org>
- Message-ID: <CA+u4+a2h0Osb0hwESJAZQrSTW5hKzjM-kNqWDcBPtrQnwVWG4g@mail.gmail.com>
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 applications. This decoration (association) occurs either manually or automatically based on what properties / classes the constraints reference. e.g. @prefix rut: <http://rdfunit.aksw.org/ns/core#> . 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. e.g. ConstraintC rut:source foaf ConstraintD rut:source foaf, skos # when a constraint involves properties from 2 ontologies ConstraintE rut:source <http://dbpedia.org> # when some constraints apply to a specific RDF Graph ConstraintF rut:source <http://example.org/applicationA> # We could even associate a constraint to a specific application IRI For validation we have 2 modes: automatic / manual automatic: 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 Manual: 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. Best, Dimitris On Fri, Nov 21, 2014 at 10:50 AM, Holger Knublauch <holger@topquadrant.com> wrote: > 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: > > ASK WHERE { > ?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 > > CONSTRUCT { > _:b0 a spin:ConstraintViolation . > _:b0 spin:violationRoot ?this . > _:b0 spin:violationPath ?property . > _:b0 rdfs:label ?message . > } > WHERE { > FILTER EXISTS { > ?this ?otherProperty ?someValue . > } . > FILTER NOT EXISTS { > ?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. > > HTH > Holger > > > -- Dimitris Kontokostas Department of Computer Science, University of Leipzig Research Group: http://aksw.org Homepage:http://aksw.org/DimitrisKontokostas
Received on Friday, 21 November 2014 10:30:11 UTC