Re: Relevant documents on SPIN

On 10/25/2014 03:50 PM, Holger Knublauch wrote:
>
> On 10/26/14, 8:17 AM, Peter F. Patel-Schneider wrote:

[...]

>> What are the expressive limits, if any, on the OWL ontology?
> None, if people activate OWL inferencing on the query graph then SPARQL will
> see those extra triples.

So, SPIN constraints should work correctly on OWL ontologies and constraints like:

A = B v C

a rdf:type A

B spin:constraint [ sp:text """ CONSTRUCT { _:cv a spin:ConstraintViolation } 
WHERE { ?this rdf:type B } """ ]
C spin:constraint [ sp:text """ CONSTRUCT { _:cv a spin:ConstraintViolation } 
WHERE { ?this rdf:type C } """ ]

or

A = E1 r . A

a rdf:type A

A spin:constraint [ sp:text """ CONSTRUCT { _:cv a spin:ConstraintViolation } 
WHERE { ?this rdf:type A } """ ]

How do I find out which constraint violations are signalled in these two cases?


>>> and a graph that
>>> contains the spin:constraints attached to the classes.
>>>
>>> use owl:imports and spin:imports closure of domain graph
>> How strong is the closure?  Can a spin:imports'd document owl:import another
>> document?
>
> Yes, for example if one library extends another library.
>
>>>      forEach triple (?class spin:constraint ?constraint)  # or sub-properties
>>>          forEach ?type := rdfs:subClassOf* ?class
>> How does this interact with allowing an OWL ontology?
>
> SPIN only looks at rdfs:subClassOf, which is used by both RDFS and OWL. There
> are no dependencies on OWL at all, except that owl:imports should be observed.

I thought that OWL inferencing could be done.  Is this not the case?

>>>              use domain graph only
>> What about enumerations that come from the ontology?
>
> I don't understand that question.

Consider the following situation:

Domain graph:
  a rdf:type A .
Ontology
  B = { b }
Constraints
  spin:constraint [ sp:text """ CONSTRUCT { _:cv a spin:ConstraintViolation } 
WHERE { ?this rdf:type B } """ ]

Is there a constraint violation here or not?  Where is this behaviour specified?

>
>>
>>>                  forEach ?instance of ?type
>> Does this mean "can be inferred to be an instance of" or something else?
> It only checks the presence of the rdf:type triple. Whether this is inferred
> or not is irrelevant.

What does "the presence of the rdf:type triple" mean then?  I'm guessing that 
this is after inference somehow, but if you allow arbitrary OWL then there can 
be infinitely many instances of a class.


>>>                      execute ?constraint, pre-binding ?this with ?instance
>>>                          -> Collect resulting constraint violations
>>
>> There appears to be quite a bit more going on than this, particularly with
>> respect to ordering.  Where is this extra specified?
>
> Constraints are unordered and could be executed in parallel.

As opposed to rules, which are potentially ordered, right?

>>> This algorithm is simplified and not optimized, but the main idea is that the
>>> CONSTRUCTs produce instances of spin:ConstraintViolation which are reported to
>>> the user as a constraint violation. There is no feedback loop here, i.e. the
>>> algorithm neither looks at previous instances of spin:ConstraintViolation, nor
>>> does it iterate.
>>
>> So spin:constraints with construct act differently from spin:rule with
>> construct?  Where is this specified?
> It is specified in the SPIN specifications and many other documents online.

Please point me to a particular authoritative document that provides this 
specification.

[...]

> Holger

Received on Saturday, 25 October 2014 23:55:24 UTC