- From: Holger Knublauch <holger@topquadrant.com>
- Date: Sat, 01 Nov 2014 06:04:40 +1000
- To: public-data-shapes-wg@w3.org
Yeah that looks right. I think we only need to define the semantics of
the CONSTRUCT case and treat ASK as syntactic sugar with default values
for the constructed ConstraintViolations.
Holger
On 11/1/14, 4:05 AM, Peter F. Patel-Schneider wrote:
> Here is my reconstruction of how SPIN constraints work, based on my
> reading
> of various SPIN documents and various presentations about SPIN
> constraints.
> Please let me know if anything is wrong.
>
> Conceptually a SPIN constraint system takes in two inputs:
> 1/ an RDF graph
> 2/ a set of SPIN constraints
>
> Each SPIN constraint is attached to a class and provides a constraint
> in the
> form of a SPARQL query fragment plus an optional SPARQL construct clause.
> The surface syntax may not always look like query fragments and construct
> clauses, but the only things that determine the meaning of a SPIN
> constraint are the query fragment and construct clause that can be
> generated
> from the surface syntax.
>
> A constraint with SPARQL query fragment F on class C is satisfied if the
> SPARQL query
> ASK {
> ?this rdf:type/rdfs:subClassOf* C .
> F }
> returns no bindings for the graph G
>
> If there is a construct clause X then the result of the constraint is the
> result of the SPARQL query
> CONSTRUCT { X }
> WHERE {
> ?this rdf:type/rdfs:subClassOf* C .
> F }
> evaluated against the graph G.
>
>
> peter
>
Received on Friday, 31 October 2014 20:05:15 UTC