SlurpyGraph and BNodes

[hsolbrig]

SlurpyGraph does not handle BNodes and FHIR is FULL of BNodes

Short term solution: IF your triplestore persists BNodes across queries, you can override the function and have SlurpyGraph treat BNodes as persistent.

Long term solution: We have been working on an enhancement to SlurpyGraph that replaces BNodes with the equivalent function that generates them (e.g. :s :p _:o --> :s :p lambda: value(:s :p)). Completion needs to be prioritized in this project.

[dbooth-boston]

@hsolbrig, Should this be treated as an R5 issue? I.e., should we try to get rid of blank nodes in R5, perhaps using skolem URIs instead? Or are you viewing this as a local-workaround issue?

[ericprud]

Where's this stand? It's probably not helpful 'cause we all know what needs to be done, but I looked around for my old implementation of preserving context for BNode queries in the FancyShExDemo. The QueryDB function in RDF.js has special handling for BNodes which keeps a "pointStack" saying how we got to where we are:

if (s._ === "BNode") {
    var t = validatorStuff.pointStack; // for readability
    for (var i = t.length-1; i && t[i].node._ === "BNode"; --i) {
        context +=
            (t[i-1].node._ === "IRI" ? t[i-1].node.toString() : ("?s"+i))+
            " "+t[i].predicate.toString()+
            " ?s"+(i-1)+" .\n";
    }
}

This was probably never tested for reverse links (<#S1> { ^:p1 ... }) a la this example. We don't see those in FHIR but it would be nice to add that in from the start anyways.

[hsolbrig]

We've punted at the moment by making it work with GraphDB. GraphDB assigns a unique id to every node via the predicate <http://www.ontotext.com/owlim/entity#id>. Whenever a BNode comes back in a query we substitute the permanent id. You can invoke it by using GraphDBSlurpyGraph programmatically or w/ a command line option.

Going to have to take a look at that snippet above -- this actually preserves all context?

[ericprud]

Ehh, it's good enough to validate simple stuff like

<n1> :p1 [ :p2 [ :p3 3 ] ] .

but I think it fails if there are repeated properties like

<n1> :p1 [ :p0 0 ], [ :p2 [ :p0 0 ], [ :p3 3 ] ] .

Specifically, I think it needs to preserve a hash of the p/o values for whatever bnode it's in. You can still create pathological cases but you can make it dig deeper in the rare case it encounters them.