Meaning of "exactly 1" cardinality constraint

[sabi...@yahoo.de]

Dear all,

in the discussion following my earlier post [1] I asked how to understand the exactly 1 cardinality constraint. The document in [2] is helpful, but I still am not able to get the expected results with my test case. In the file "EventRestriction.ttl" I stated, that an Event is supposed to have exactly 1 incoming ControlFlow. When validating the epcInstanceOntology.ttl I get the message: "Data is valid". But when I change the data (by removing the incoming ControlFlow of the individual :e2, the corresponding file is "epcInstanceOntology_ConstraintViolation1.ttl") I still get "Data is valid" as result of the validation. How is this possible? Now we have an individual ":e2" with 0 incoming ControlFlows, which in my understanding contradicts exactly 1 constraint. Considering the Closed World Assumption in Stardog, I would expect a violation now.

My questions:
1. Can you reproduce these validation results?
2. If yes. Is this a correct result? Would be greatful for some explanation.

Thanks a lot!



[1] https://groups.google.com/a/clarkparsia.com/forum/#!topic/stardog/PPrGQvLym9U
[2] http://docs.stardog.com/icv/icv-specification.html

[Evren Sirin]

There are two different problems here. First you are using incorrect
URIs. In eventRestriction.ttl you have
<http://www.uni-oldenburg.de/sabina/epcSchemaOntology#hasOutgoingFlow>
but in epsInstanceOntology.owl you have
<http://www.uni-oldenburg.de/sabina/epcInstanceOntology#hasOutgoingFlow>.
You need to fix the URIs to match.

The second issue is more subtle. Due to the way exact cardinality
constraints are translated to SPARQL, you need to enable reasoning
during validation to get the violations even tough it looks like you
don't need reasoning. So you need to run the following command:

$ bin/stardog icv validate -r sl myDB

If you are interested in details, look at SPARQL translation for your
constraint which you can see with the icv convert command:

SELECT DISTINCT *
FROM <tag:stardog:api:context:all>
WHERE {
?x0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
<http://www.uni-oldenburg.de/sabina/epcSchemaOntology#Event> .
{
?x0 <http://www.uni-oldenburg.de/sabina/epcSchemaOntology#hasIncomingFlow>
?x1 .
?x1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
<http://www.uni-oldenburg.de/sabina/epcSchemaOntology#ControlFlow> .
?x0 <http://www.uni-oldenburg.de/sabina/epcSchemaOntology#hasIncomingFlow>
?x2 .
?x2 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
<http://www.uni-oldenburg.de/sabina/epcSchemaOntology#ControlFlow> .
FILTER (?x1 != ?x2)
}
UNION
{
FILTER NOT EXISTS {
?x0 <http://www.uni-oldenburg.de/sabina/epcSchemaOntology#hasIncomingFlow>
?x3 .
?x3 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
<http://www.uni-oldenburg.de/sabina/epcSchemaOntology#ControlFlow> .
}
?x0 <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
<http://www.w3.org/2002/07/owl#Thing> .
}
}

Note that, the translation inserts {?x0 rdf:type owl:Thing} pattern at
the end because we cannot have just a FILTER NOT EXISTS element inside
a UNION. If you have reasoning turned on {?x0 rdf:type owl:Thing}
would match any instance. Without reasoning, it would not match
anything and no violation is detected for missing values. If you split
your constraint into two (one minQualifiedCardinality and one
maxQualifiedCardinality) then this issue would go away. This is not
ideal behavior so we'll think about another solution in the future.

Best,
Evren

> --
> -- --
> You received this message because you are subscribed to the C&P "Stardog"
> group.
> To post to this group, send email to sta...@clarkparsia.com
> To unsubscribe from this group, send email to
> stardog+u...@clarkparsia.com
> For more options, visit this group at
> http://groups.google.com/a/clarkparsia.com/group/stardog?hl=en

[sabi...@yahoo.de]

Dear Evren,
thanks again for your help!
As you said, when using the validate command with reasoning, Stardog produced the expected results.

When testing I  noticed that I also had an issue with some prefixes (this problem was introduced by myself and has nothing to do with Stardogs functionality). So I first had to fix this. Then, following your advice and using the "stardog icv validate -r sl myDB" command would work.

Best regards,
Sabina