BIND support

[adel-ayara]

does Nemo support BIND to create new instances?

[mmarx]

I am not sure what “instances” refer to, so please let me know if you meant something else. There is no BIND builtin as in SPARQL, but variable bindings in rules can be written using = as follows:

q(?x, ?y) :- p(?x), ?y = <https://example.org/test> .

Alternatively, you can write the value inline:

q(?x, <https://example.org/test>) :- p(?x) .

If ?y also appears in the body, this acts as a filter condition. The following program, e.g., derives p(23), but not p(42).

p(23, <https://example.org/test>) .
p(42, <https://example.org/other>) .

q(?x) :- p(?x, ?y), ?y = <https://example.org/test> .

Again, this is equivalent to inlining the value:

p(23, <https://example.org/test>) .
p(42, <https://example.org/other>) .

q(?x) :- p(?x, <https://example.org/test>) .

[adel-ayara]

Let me provide a simple example to illustrate our case: we want to implement the following rule:

if 2 drive paths share the same lane boundaries then create a lane instance and associate these 2 lane boundaries to this new lane

So given:

:dp1 a :DrivePath ;
    :hasLeftLB :lb1 ;
    :hasRightLB :lb2 .

:dp2 a :DrivePath ;
    :hasLeftLB :lb1 ;
    :hasRightLB :lb2 .

I want to infer knowing that :lane1 doesn't exist in my knowledge base

:lane1 a: Lane ;
    :hasDP :dp1 ;
    :hasDP :dp2

[mmarx]

You could use rules like the following (I'm assuming a prefix for rdf has been declared already):

sameBoundaries(?dp1, ?dp2) :-     
    triple(?dp1, rdf:type, DrivePath),
    triple(?dp1, hasLeftLB, lb1),   % or maybe ?lb1 here if the name doesn't matter
    triple(?dp1, hasRightLB, lb2),  % or maybe ?lb2
    triple(?dp2, rdf:type, DrivePath),
    triple(?dp2, hasLeftLB, lb1),   % or maybe ?lb1
    triple(?dp2, hasRightLB, lb2),  % or maybe ?lb2
    ?dp1 != ?dp 2 .

triple(lane1, rdf:type, Lane), 
triple(lane1, hasDP, ?dp1),
triple(lane1, hasDP, ?dp2) :- sameBoundaries(?dp1, ?dp2) .

If the name lane1 is not important and you just want to have some lane there, you can existentially quantify the lane:

triple(!lane, rdf:type, Lane), 
triple(!lane, hasDP, ?dp1),
triple(!lane, hasDP, ?dp2) :- sameBoundaries(?dp1, ?dp2) .

[adel-ayara]

I tried to test these rules in Nemo playground with the following RDF data added as input from local file :

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix lbm: <http://www.bmw.de/Foresight/Map#> .

lbm:lb1 rdf:type lbm:LaneBoundary .
lbm:lb2 rdf:type lbm:LaneBoundary .

lbm:dp1 rdf:type lbm:DrivePath ;
    lbm:hasLeftLB lbm:lb11 ;
    lbm:hasRightLB lbm:lb12 .

lbm:dp2 rdf:type lbm:DrivePath ;
    lbm:hasLeftLB lbm:lb11 ;
    lbm:hasRightLB lbm:lb12 .

and the following rules

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix lbm: <http://www.bmw-carit.de/Foresight/Map/Ontologies/Low/behaviorMap#> .

sameBoundaries(?dp1, ?dp2) :-     
    triple(?dp1, rdf:type, lbm:DrivePath),
    triple(?dp1, lbm:hasLeftLB, ?lb1),
    triple(?dp1, lbm:hasRightLB, ?lb2),
    triple(?dp2, rdf:type, lbm:DrivePath),
    triple(?dp2, lbm:hasLeftLB, ?lb1), 
    triple(?dp2, lbm:hasRightLB, ?lb2),
    ?dp1 != ?dp2 .

triple(!lane, rdf:type, lbm:Lane), 
triple(!lane, lbm:hasDP, ?dp1),
triple(!lane, lbm:hasDP, ?dp2) :- sameBoundaries(?dp1, ?dp2) .

But it didn't work, I get 0 facts derived

[mmarx]

You will need to add an import declaration for the RDF as well:

@import triple :- turtle{resource="data.ttl"} .

Also the prefix definitions for lbm do not agree, so the rules will never match. See the full example in the Nemo playground.

[adel-ayara]

Yes I realized this issue and I fixed it but I get new lanes derived (see attached file)
results-triple.csv

[mmarx]

This is because both sameBoundaries(lbm:dp1, lbm:dp2) and sameBoundaries(lbm:dp1, lbm:dp2) are matches for the rule that derives new lanes. See the Playground I linked above for one of the possible ways to avoid this (you could also move the ordering check to the lane rule, e.g.:

lane(!lane, ?dp1, ?dp2) :- sameBoundaries(?dp1, ?dp2), COMPARE(STR(?dp1), STR(?dp2)) < 0 .

[adel-ayara]

Thanks @mmarx!
Last question from my side: is it possible to generate new lanes with different instance names e.g. lane1, lane2, etc.?

[mmarx]

Different invocations of the rule will lead to different named nulls (what would be blank nodes in RDF). We might provide an option to skolemise those on export at some point (i.e., turn those into IRIs of a particular form), but even then, the names will not be predictable, since they depend on, e.g., the order of rule applications: what might be lane1 in one run of a program could be lane23 on another run of the program (even on the same data).

[adel-ayara]

It doesn't matter if the lane instance names are different for different runs. The most important is that we materialise new lane instances and their new relationships

[mmarx]

Then just going with the named nulls sounds like it should be fine, if you export to RDF, they will turn into bnodes. If you need named RDF nodes (without any particular constraints on the names), then Skolemisation would give you that – feel free to open a feature request.