IntelligentGraph

[peterjohnlawrence]

I've been working on a SAIL, which I've called IntelligentGraph. IntelligentGraph allows literals to be scripts (Javascript, Groovy, etc). These scripts get executed when the values are requested. Thus we can add calculations directly into the graph.
Performing calculations alone would not be very useful, so I added the ability for a script to access other nodes within the graph, just like an Excel cell formula can access another cells' values. The 'language' for accessing these other nodes is PathQL.

• The principles of IntelligentGraph are described here.
• If anyone is interested PathQL is described here.
• Also I have used Jupyter as an IDE to IntelligentGraph and RDF4J, shown here
• Everything is here in GitHub

Interested in the RDF4J communities feedback

[abrokenjester]

This looks great. I like the approach, blending what is essentially custom rule-based inference right into the graph model itself.

Regarding PathQL: admittedely I've only skimmed things, but all the examples I've seen sofar would be expressible in regular SPARQL syntax (perhaps not as a single path expression, but still as a basic graph pattern). For example, this PathQL expression:

/:parent[:gender :female]/:parent[:gender :male, :birthplace [rdfs:label ‘Maidstone’]]/:parent

would in regular SPARQL syntax be something like:

?this :parent [ :gender :female ;
                       :parent [ :gender :male ;
                                     :birthPlace [ :rdfs:label 'Maidstone ] ;
                                     :parent ?target
                               ] 
              ].

or if you prefer a one-liner:

?this :parent [ :gender :female; :parent [ :gender :male; :birthPlace [ :rdfs:label 'Maidstone' ]; :parent ?target ]].

Can you elaborate on what motivated you to introduce a custom syntax that is almost but not quite SPARQL? Purely readability, or are there features in PathQL that are not as easily expressible in SPARQL as this example?

[peterjohnlawrence]

I did not intend to create an alternative to SPARQL, GraphQL, or SERQL but it happened by accident:-)
My primary development was the embedding of scripts into the graph, by allowing literal nodes to be interpreted as scripts that were executed whenever their value is requested. This is a bit analogous to a spreadsheet but uses the graph as the scaffolding that links the nodes together rather than the matrix arrangement of a spreadsheet.
One essential feature of a spreadsheet formula is the ability to reference other spreadsheet cells. So in IntelligentGraph, I needed to access other nodes relative to the current or '_this' node. Given that the scripts could access any JAR, one could use any language but I wanted it to be syntactically simple, aka syntactic sugar. An example of a script to calculate the total production of a process plant might be:

“var totalProduction =0.0;
for(Resource stream : _this.getFacts(‘:hasProductStream’))
{
   	totalProduction += stream.getFact(‘:massFlow’);
}
return totalProduction; "^^:groovy ; 

Even this is a bit verbose so it evolved to:

“_this.getFacts(‘:hasProductStream/:massFlow’).total()"^^:groovy ;

To be honest, I could still have used SPARQL, but there were two requirements that would have made its use within the script cumbersome:

1. The models that I encountered invariably require reification and their variants of 3rd/4th order models. Expressing these in SPARQL is possible but verbose.
2. Some of the references to other nodes are transitive or of an indeterminate number of steps.

To solve 1, I allowed accessing reified statements as follows:

“_this.getFacts(‘@:hasProductStream/:massFlow’).total()"^^:groovy ;

Where @:hasProductStream is short-hand for a reference to the rdf:object of a reified statement, where _this is the rdf:subject, and :hasProductstream is the rdf:predicate

To solve 2, I added the propertypath-style (but which did not make it into the current standard) of repeated predicates. As an example, to count the number of ascendents I could express it as:

“_this.getFacts(‘:hasParent{1,5}’).count()"^^:groovy ;

So by now, I am committed to creating this language so like all good intentions, it grew to include filtering, de-reification, and much more.

“_this.getFacts(‘:hasParent[:gender :male]{1,5}’).count()"^^:groovy ;

Although it started out as just part of the capability for a calculation node to access other nodes, I discovered it was quite useful to use standalone when discovering paths through knowledgegraphs as in the following examples. This was particularly important as I had created some SPARQL extension functions for path searching implementing InverseMagicProperty. Unfortunately, these were disappearing along with the rest of SPIN support, so I needed a way to access this capability.

Note that these return the paths as the results rather than just the facts.

So, like topsy, it grew out of a simple need, but to a point which is very useful (well I think so:-))

[kenwenzel]

This is very interesting. It reminds me of the ripple language for processing RDF which itself can be represented in RDF.

A small drawback of your approach is the representation of programs as string literals. This makes it harder for RDF tools to inspect and/or automatically adapt the code in case of changes in the RDF model (like renamed properties etc.).
Another point is how prefixes are resolved to convert names like :massFlow to IRIs.

I'm also working on a similar approach to yours that combines OpenMath and RDF for mathematical rules.
Its associated textual syntax (POPCORN-LD) allows to express your summation above as:

:totalProduction = sum(@@hasProductStream, $stream -> @massFlow($stream))

By using an RDF serialization for OpenMath the rules themselves can also be encoded as RDF graphs.

Here are some pointers to our work:

• Initial overview paper
• Details of the OpenMath RDF encoding
• Java source code of the PoC implementation
• RDF Content Dictionary for OpenMath that allows to query RDF graphs from OpenMath expressions

[peterjohnlawrence]

A small drawback of your approach is the representation of programs as string literals.

Agreed

Another point is how prefixes are resolved to convert names like :massFlow to IRIs

I use the namespaces defined within RDF4J to resolve qnames. So if RDF4J recognizes it as a namespace, then so do the scripts and PathQL.