I tried to use a rule via ICV on a virtual graph. Does that work ?
In my database I have topology information for a building stored in a somewhat unwieldy format. Records of type RoomToRoomAssociation refer to Rooms via fromRoom and toRoom references.
What I would like to have is a connectedTo relation between Room entities. This is what I tried:
IF {
?a a r:RoomFromToAssociations .
?a r2r:ref-ToRoom ?to .
?a r2r:ref-FromRoom ?from .
}
THEN {
?from r:connectedTo ?to .
?to r:connectedTo ?from .
}
Is my understanding of ICV rule Syntax correct ?
If it does not work with virtual Graphs - would it work if I materialize them ?
It might help if you were to include a little more detail on what you mean by
Did you define your rule in a virtual graph via mapping? I doubt you did, but I guess someone might try but that leads to an interesting question, can you make a virtual graph your default schema graph?
Are you expecting data from your virtual graph to contribute to satisfying the constraint or are you expecting the constraint to apply to just the virtual graph? There's another question for myself, are virtual graphs a part of the default graph when the default graph is set to "all"?
Can you include a small example of what data you have in Stardog, what you have in virtual graphs, and what behavior you expected to see and what behavior you observed?
Are you running ICV in regular mode or guard mode? Do you have reasoning enabled or not? Now that I think about it I don't think you can use a rule as a constraint. You can have a rule that can be used with reasoning to satisfy the constraint. Constraints can be defined in OWL or SPARQL but I don't think you can define them as a rule. I could be completely wrong on that though.
I have an SQL database which is giving me topology of a building in the following form:
A —fromRoom-> R1
A –toRoom-> R2
to denote that there is a connection from room R1 to room R2.
What I’d like to have is to get these aggregated into a simpler schema of the form
R1 –connectedTo-> R2
where connectedTo would be an inverse relation obviously.
Maybe I am going down the wrong road, but had understood
I had tried to add the rules shown via
I removed your personal contact information from your post on the off chance that you didn’t actually want to share your personal contact information with the internet. Please feel free to edit the post and add it back if that was your intention.
I would have gotten back sooner but I was scratching my head trying to figure out why reasoning wasn’t working only to realize I was missing a colon at the end of a prefix.
Depending on what exactly you’re looking to do I think you’re close but I don’t think you’re looking for ICV and you can do what you’re looking for with just reasoning.
Working with the following example data and rule.
prefix rule: <tag:stardog:api:rule:>
insert data {
:a :fromRoom :r1 ;
:toRoom :r2 .
[] a rule:SPARQLRule;
rule:content """
IF {
?a :fromRoom ?r1 ;
:toRoom ?r2 .
THEN {
?r1 :connectedTo ?r2 .
}""" .
}
I’m not sure what :a is supposed to be but assuming it’s just some arbitrary node and you don’t care about it you can write the rule a little more compactly with a propery path ?r1 ^:fromRoom/:toRoom ?r2
Executing the folllowing query with reasoning
select * where { ?r1 :connectedTo ?r1 }
Should return:r1 :connectedTo :r2
You can add the reverse and you’ll need to be mindful if going from a room to :a and back to the same room makes them connected.
What you can’t do with either reasoning or ICV is remove the :fromRoom and :toRoom statements and replace them with :connectedTo
What you can do with ICV is that :a must explicitly state that it has a :fromRoom and a :toRoom when you insert some :a thing.
thanks for the ideas and corrections. The ICV documentation on rules looked indeed to me as if the reasoner would infer additional knowledge from them.
You pointed me to the correct path. I haven’t yet achieved to bring it to work so far using my virtual graph. I will revert to test it with some toy data loaded into the system “by hand” and get back to you.
I’m glad to hear you’re on the right path. I forgot to mention that you might want to check to make sure the following configuration setting is set to true.
reasoning.virtual.graph.enable
It’s enabled by default but I didn’t want you to spend a lot of time trying to figure out why it might not be working with virtual graphs only to find out that wasn’t set.
The difference between reasoning and ICV might be a little confusing because they can use the same language, OWL, which is really nice since you only need to learn one language. The difference is how you interpret the language. The other thing that can probably be confusing is that they can work independently or together.
ICV is what you must know, reasoning is what you can figure out from what you already know, and reasoning with ICV says you need to either know it or be about to figure it out from what you know.
Using reasoning you would know that when someone gives you flowers it means they love you. A constraint would be, you must tell them that you love them, giving them flowers isn’t enough, you need to say the words. A constraint with reasoning would be you can either tell them that you love them or do something so they can figure out that you love them, like buying them flowers.
Just a quick followup. I had wondered if rules were supported in constraints and indeed they are, "In addition to OWL, ICV constraints can be expressed in SPARQL and Stardog Rules". I'm happy to say that most times when you say to yourself, "It seems like you should be able to..." with Stardog, you can
