RE: Relevant documents on SPIN

Peter,

You may be envisioning something much more complex than what it really is.

As mentioned below, rdfs:subClassOf axioms are the only axioms that are considered.

< 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.>

Thus, no constraints would be executed for your first example because constraints in the example are associated with classes B and C, there are no subclass relationship between these classes and class A and the only instance we have is a member of class A.

If the model included triples:

:A rdfs:subClassOf :B
:A rdfs:subClassOf :C

Then both constraints would be executed - for B and for C. How these triples got added to the model is outside of the area of concern for SPIN constraints checking. For example, if you have a model that is rich in OWL axioms, you could run it through a DL reasoner before checking for the constraint violations.

As an aside, there is no need to say in the WHERE clause {?this a :B} or {?this a :C}. Using ?this already assumes that we are talking about a member of the class constraint is associated with.

Irene

-----Original Message-----
From: Peter F. Patel-Schneider [mailto:pfpschneider@gmail.com] 
Sent: Saturday, October 25, 2014 7:55 PM
To: Holger Knublauch; public-data-shapes-wg@w3.org
Subject: 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 Sunday, 26 October 2014 00:34:03 UTC