Re: a view of SPIN constraints

On 11/4/14, 3:06 AM, Peter F. Patel-Schneider wrote:
> One aspect of this definition is that SPIN does not completely abide 
> by the RDFS definition of the instances of classes.

Could you clarify - do you mean sub-properties of rdf:type?

And in general, it is not the goal of SPIN to have full RDFS support. 
RDFS doesn't have intuitive semantics, esp rdfs:domain and range are a 
source of frequent user pain.

Thanks
Holger


>
> 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 20:59:30 UTC