SPARQL equivalent of Datomic Pull Syntax

[RickMoynihan]

Why?

Providing a declarative way to make hierarchical (and possibly nested) selections of information about entities, that return data structured into a tree (perhaps JSON-LD) would be a useful feature.

Evidence for the utility can be found in the success of Datomic pull syntax and how it's been copied into other stores. It supports a similar usecase to GraphQL, but is I believe better designed and supports namespaced properties.

Providing a SPARQL feature similar to pull syntax would I think be highly valuable; however I suspect the size of the feature may be too big for a point release and would perhaps need to be part of a bigger effort SPARQL 2.0 effort?! Regardless I mention it to document the idea.

It would also I think be a much better solution to #48 which I filed, which is largely trying to solve the same problem some time ago.

Previous work

• Datomic pull syntax
• GraphQL
• EQL - EDN Query Language (Datomic inspired specification with a few extra bells and whistles)
• I believe Datascript may also support a similar "pull" feature.

Proposed solution

An RDF-like variant for illustration might look like this.

<PREFIX_BLOCK>

[dcat:record [dcterms:title
              dcterms:modified
              {foaf:primaryTopic [dcterms:title
                                  dcterms:description]}]]

It would then return a tree (presumably in something like JSON-LD):

{"dcat:record" [{"@id" "http://crimes/record",
                "dcterms:title" "Crimes DCAT Record",
                "dcterms:modified" "01-01-2019",
                "foaf:primaryTopic" {"@id" "http://crimes/dataset",
                                    "dcterms:title" "Crimes",
                                    "dcterms:description" "Crimes by area"}}]}

Unlike RDF Datomic has an explicit schema that documents the cardinality of properties; so there may need to be affordances in the specification/implementations to handle the fact that a predicate may have one or many values.

Considerations for backward compatibility

It should be implemented as not to break anything, but will likely require significant additions to the SPARQL grammar.

[Aklakan]

This issue is similar to my proposal in #127 in the following regard:

• Both issues are in the core about extracting graph fragments with a starting node with the ultimate goal to facilitate an object mapping. It is a form of object mapping:

Unlike RDF Datomic has an explicit schema that documents the cardinality of properties

• My proposal is about enhancing the CONSTRUCT query form so that it is possible to extract graph fragments upon which a subsequent object mapping can be applied. I recently described an example about retrieval of rdf:Lists via SPARQL with a subsequent declarative object mapping to objects here.

So achieving full control over a JSON mapping would certainly work with a combination of my described rooted construct queries and a separate schema definition - I wonder whether this can be combined into compact syntax for the JSON use case.

[VladimirAlexiev]

There are a bunch of issues that scream "I need better ways to pull data out of graphs; CONSTRUCT and SELECT are not enough":

#39, #48, #126, #127, #128