Miscellaneous features wanted in SPARQL

[dbooth-boston]

From Adrian Gschwend in #44:

the place where I see most need right now is discussing the future of SPARQL. I guess we could have SPARQL 1.2 defined relatively fast with a bunch of stuff which is missing in the current spec but would be very useful in the real world. Some of them are implemented by various stores but not standardized so it's store-proprietary. For bigger stuff like the PATH concept implemented in Stardog it would make sense to think about SPARQL 2.0. There we would be allowed to break things IMHO. Again, a lot of stuff would either be syntactic sugar or modest extensions of the spec.

[VladimirAlexiev]

• https://www.stardog.com/blog/extending-the-solution (mentioned in the above list)
• https://www.stardog.com/blog/a-path-of-our-own (mentioned in the above comment)
• BlazeGraph WITH (using the results of a complex query within another)

[VladimirAlexiev]

Related: #18, #28, #54, #55, #63.
@dbooth-boston, Andy @afs asks "Can we have a "SPARQL" label on these, please?"

[afs]

Removing "SPARQL: " on transferred issue.

[ktk]

Now there is a graph path query in GraphDB:

• https://graphdb.ontotext.com/documentation/9.9/enterprise/graph-path-search.html

[afs]

See also issue label function for calling external code.

[ktk]

Anyone still sees a reason to keep this issue open? With #191 I would say everything that was mentioned here is captured by a more on specific issue.