Stardog rules and ICV

[sabi...@yahoo.de]

Dear all,

I am a Stardog newbie and have a hard time figuring out how to work with stardog rules and ICV. So any hint will be appreciated!

Stardog is running on my PC (running with Windows 7) and I created a db, where I would like to experiment with the ICV. I have an ontology (describing the syntax of a process modelling language, namely Event driven process chains) and an instance of a process (please see attached file a_box.gif for a graphical representation of the process. Please disregard the german labels, they are not important in this case). The ontology and related individuals are contained in one file.

Question 1. How to express the constraints? I found the documentation [1] , where it is strongly recommended to use the native stardog rules syntax.
So what I did right now is the following:
a. I generated the ontology (which contains both the T-Box and the A-Box) in Protege and saved it in the Turtle Syntax. The resulting file was stardog_epk.ttl.
b. In a simple text editor, I tried to create a simple rule. In my example I have the class Function, the class ControlFlow, and the objectProperty :hasIncomingFlow with domain Function and range ControlFlow. I would like to formulate a rule stating that if some individual ?f is a Function, and some ?c is a ControlFlow, then ?f has to have exactly one :hasIncomingFlow. Would this be working?:
@prefix rule: <tag:stardog:api:rule:> .
[] a rule:SPARQLRule;
   rule:content """
 
     IF {
        ?f a :Function;
        ?c a :ControlFlow;
     }
     THEN {
         :hasIncomingFlow(?f,?c) exactly 1
     }""" .

I put this rule in the file rule1.ttl

3. I now would add this file to the db.

Question 2: Is it necesarry  to separate the rules from my Ontology definition and store it in a separate file?
Question 3: How should I edit my rules? Using the text editor? Is there is user-friendlier way? Currently, I am not even sure, my rule file conforms to the Stardog rule syntax.

Question 4: As for the testing, I was planning to add some violation of this rule to the A-Box and then use the ICV funtionality in Stardog. How can I make sure, my rule is not ignored by Stardog? In the documentation [2] it says to include "    following line in the logging.properties file in STARDOG_HOME:

        com.clarkparsia.blackout.level = ALL " But I did not find the logging.properties file. Is it possible the documentation means the stardog.properties file?



Many thanks in advance!

Best regards,
Sabina



[1] http://docs.stardog.com/owl2/#sd-User-defined-Rule-Reasoning
[2] http://docs.stardog.com/owl2/#sd-Not-Seeing-Expected-Answers-

[Evren Sirin]

On Fri, Mar 14, 2014 at 10:48 AM, <sabi...@yahoo.de> wrote:
> Dear all,
>
> I am a Stardog newbie and have a hard time figuring out how to work with
> stardog rules and ICV. So any hint will be appreciated!
>
> Stardog is running on my PC (running with Windows 7) and I created a db,
> where I would like to experiment with the ICV. I have an ontology
> (describing the syntax of a process modelling language, namely Event driven
> process chains) and an instance of a process (please see attached file
> a_box.gif for a graphical representation of the process. Please disregard
> the german labels, they are not important in this case). The ontology and
> related individuals are contained in one file.
>
> Question 1. How to express the constraints? I found the documentation [1] ,
> where it is strongly recommended to use the native stardog rules syntax.

If you are going to use rules, we recommend Stardog rules syntax
instead of the SWRL syntax. Otherwise using OWL for constraints is
fine and might even be preferable since OWL constraints are typically
more succinct.

> So what I did right now is the following:
> a. I generated the ontology (which contains both the T-Box and the A-Box) in
> Protege and saved it in the Turtle Syntax. The resulting file was
> stardog_epk.ttl.
> b. In a simple text editor, I tried to create a simple rule. In my example I
> have the class Function, the class ControlFlow, and the objectProperty
> :hasIncomingFlow with domain Function and range ControlFlow. I would like to
> formulate a rule stating that if some individual ?f is a Function, and some
> ?c is a ControlFlow, then ?f has to have exactly one :hasIncomingFlow. Would
> this be working?:
> @prefix rule: <tag:stardog:api:rule:> .
> [] a rule:SPARQLRule;
> rule:content """
>
> IF {
> ?f a :Function;
> ?c a :ControlFlow;
> }
> THEN {
> :hasIncomingFlow(?f,?c) exactly 1
> }""" .
>
> I put this rule in the file rule1.ttl

There are couple things wrong with this rule including the syntax.
What you are trying to express here is a regular cardinality
constraint which would be the following OWL axiom:

:Function subClassOf hasIncomingFlow exactly 1 ControlFlow

Expressing cardinality constraints as SPARQL rules would be much harder.

>
> 3. I now would add this file to the db.
>
> Question 2: Is it necesarry to separate the rules from my Ontology
> definition and store it in a separate file?

Yes, because constrains are added to a Stardog database using
"stardog-admin icv add" command where you'd pass the file containing
the constraints.

> Question 3: How should I edit my rules? Using the text editor? Is there is
> user-friendlier way? Currently, I am not even sure, my rule file conforms to
> the Stardog rule syntax.

For the above OWL constraint you can still use Protege. If you are
going to use rules then you can use SWRL rules too since Protege
provides support for writing SWRL rules. In order to use SPARQL rules
you'd need to at least familiarize yourself more with SPARQL syntax.

>
> Question 4: As for the testing, I was planning to add some violation of this
> rule to the A-Box and then use the ICV funtionality in Stardog. How can I
> make sure, my rule is not ignored by Stardog? In the documentation [2] it
> says to include " following line in the logging.properties file in
> STARDOG_HOME:
>
> com.clarkparsia.blackout.level = ALL " But I did not find the
> logging.properties file. Is it possible the documentation means the
> stardog.properties file?
>

Stardog uses SLF4J logging which means you can use whatever logging
framework you want and different frameworks have different ways to
configure them. The suggestion in the documentation is for using JDK
logging which is the default framework Stardog uses. If you add a
logging.properties file to your STRAOG_HOME directory with the
following lines the reasoning warnings would be printed in the log:

handlers = java.util.logging.ConsoleHandler
java.util.logging.ConsoleHandler.level = WARNING
com.clarkparsia.blackout.level = ALL

Best,
Evren

>
>
> Many thanks in advance!
>
> Best regards,
> Sabina
>
>
>
> [1] http://docs.stardog.com/owl2/#sd-User-defined-Rule-Reasoning
> [2] http://docs.stardog.com/owl2/#sd-Not-Seeing-Expected-Answers-
>

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

thank you a lot for the helpful answer.

I managed to express one constraint (stating that a Event is supposed to have exactly one incoming ControlFlow and exactly one outgoing ControlFlow) by formulating it as a restriction in Protege. I stated:
(hasIncomingFlow some ControlFlow) and (hasIncomingFlow exactly 1 ControlFlow) in the Protege class expression editor. See also attached file "event_restriction.ttl".
I used my test data (file epc_withSyntaxViolation.ttl), where the Event :e2 is violating the contraint, because it has two incoming ControlFlows, namely :kf11 and :kf3).  This data was added to my stardog data base named  "epkDB." In this DB the ICV_ENABLED is set to false. Using the "stardog-admin icv add" command the file "event_restriction.ttl" was added to the epkDB.

After that the command "stardog icv validate epkDB" gives the result: "Data is NOT valid" with an explanation.

When formulating the constraint in Protege I had one question regarding the meaning of the "exactly 1" cardinality. What is the difference between "exactly 1", "max 1"? Intuitively I would think, that for exactly 1 the 0 is not allowed. So O expect that stating hasIncomingFlow exactly 1 ControlFlow for some entity would result in a constraint violation, when it has no incoming controlflow. But when I tested corresponding data, the result of validation in stardog still was that the data is valid. Therefore I added hasIncomingFlow some ControlFlow to the constraint. Is this correct?

With regards to the handling of contraints in Stardog. Is there a way to know which constraints are included in a data base? So far, I did not find a command which would facilitate this.
And when droping a constraint: In case several constraints where added to the db (each one in a seperate file), is it possible to drop one/some of them while leaving the remaining constraints in the data base? I am asking, because the command "stardog-admin icv drop" drops all constraints at once, right?

Thanks again!
Regards,
Sabina

[Zachary Whitley]

You can try taking a look at the CLI command

> stardog icv convert ...

and compare the difference between "exactly 1" and "max 1" to see how Stardog is interpreting the constraint.

You can see what constraints are defined in the db with

> stardog icv export ...

You can drop specific constraints with

> stardog icv remove

(the icv commands have changed a little bit so I'm assuming you're using the latest release)

You can see the exact definitions at http://docs.stardog.com/icv/icv-specification.html

I've wondered about a few of them myself. The examples in the docs are great but I was wondering if a a short explanation for each one of the axioms could be added to the docs? The specification is rigorous but sometimes I have a difficult time interpreting it.

I'm interested to hear what Evren has to say.

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

To unsubscribe from this group and stop receiving emails from it, send an email to stardog+u...@clarkparsia.com.

[sabi...@yahoo.de]

Hello,
as for the "stardog icv convert" and "stardog icv export" commands: thanks for your suggestions. I will experiment with them.

You can drop specific constraints with

> stardog icv remove

(the icv commands have changed a little bit so I'm assuming you're using the latest release)

I am using the latest Stardog release (2.1.1) and I could not find the "stardog icv remove" command there.

You can see the exact definitions at http://docs.stardog.com/icv/icv-specification.html

I've wondered about a few of them myself. The examples in the docs are great but I was wondering if a a short explanation for each one of the axioms could be added to the docs? The specification is rigorous but sometimes I have a difficult time interpreting it.

I'm interested to hear what Evren has to say.

 Thanks,
Sabina

[Mike Grove]

On Thu, Mar 20, 2014 at 6:19 AM, <sabi...@yahoo.de> wrote:

Hello,
as for the "stardog icv convert" and "stardog icv export" commands: thanks for your suggestions. I will experiment with them.

You can drop specific constraints with

> stardog icv remove

(the icv commands have changed a little bit so I'm assuming you're using the latest release)

I am using the latest Stardog release (2.1.1) and I could not find the "stardog icv remove" command there.

You can see the man page for it here [1]

Cheers,

Mike

[1] http://docs.stardog.com/man/icv-remove.html

 

You can see the exact definitions at http://docs.stardog.com/icv/icv-specification.html

I've wondered about a few of them myself. The examples in the docs are great but I was wondering if a a short explanation for each one of the axioms could be added to the docs? The specification is rigorous but sometimes I have a difficult time interpreting it.

I'm interested to hear what Evren has to say.

 Thanks,
Sabina

--

[sabi...@yahoo.de]

Thanks Michael!

Now I see, the confusion was "stardog icv" vs. "stardog-admin icv" commands.

Best,
Sabina