Re: a view of SPIN constraints

One aspect of this definition is that SPIN does not completely abide by the 
RDFS definition of the instances of classes.

peter

On 10/31/2014 01:04 PM, Holger Knublauch wrote:
> 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 Monday, 3 November 2014 17:06:59 UTC