#455: Integrate SPARQL Functions

[simonstey]

Closes #455

• See this document rendered online here

[simonstey]

Do we want to have the SPARQL function sections being populated dynamically (from https://github.com/w3c/sparql-query/blob/main/sparql-ns.ttl ) or just updated on demand?

[HolgerKnublauch]

I am afraid the proper process would be:

1. We create a new TTL file that owl:imports the base file
2. In that file we add triples that are useful for rendering, e.g.:
   a) grouping by category
   b) deep links into the SPARQL spec
3. Then the content can be created dynamically, if we have a TTL parser available.
4. Maybe the TTL will be accepted by the sparql main document too, but I am not sure about the update cycle.

This is of course a lot of work but will be paying off on the long term because the info will be machine readable, e.g. for syntax-directed editors.

BTW the diff is huge - what happened?

[simonstey]

I am afraid the proper process would be:

1. We create a new TTL file that owl:imports the base file

2. In that file we add triples that are useful for rendering, e.g.:
   a) grouping by category
   b) deep links into the SPARQL spec

3. Then the content can be created dynamically, if we have a TTL parser available.

4. Maybe the TTL will be accepted by the sparql main document too, but I am not sure about the update cycle.

This is of course a lot of work but will be paying off on the long term because the info will be machine readable, e.g. for syntax-directed editors.

BTW the diff is huge - what happened?

I messed up the formatting.. will fix that next

[afs]

2. deep links into the SPARQL spec

If contributed back to RDF & SPARQL WG, I'm sure that could get incorporated into sparql-ns.

[afs]

SPARQL functions work on arguments that are single RDF terms. In [ sparql:agg-count ( ?values ) ] there isn't a term for ?values. (The pain of lists not being first class in RDF.)

SPARQL Aggregates tied into the way GROUP BY works (e.g. SUM(?X+1)) to produce sets - the design means the lists are solely within aggregates a don't leak out to general evaluation. SPARQL Aggregates are not directly usable as node expressions.

shnex has it's own aggregates and that's probably the way to go - I think that defining an adaption layer to get SPARQL aggregates to work is not that different from shnex's aggregates so there is no advantage to SPARQL aggregates.

shnex aggregates working on lists which integrates with the way shnex is e.g. sh:values.

[ sparql:coalesce ( ?optionalValue "default" ) ] is n-ary including a "no result" error.
It is also special because of it's error handling - ditto logical-and, and logical-or.

I don't see that node expressions can have variables other than the environment : #498 (comment)

[afs]

Where is infix used in node expressions?

[HolgerKnublauch]

It is not but the information is useful to capture IMHO, to produce human-readable syntax.

[afs]

That would also need infix precedence.

[simonstey]

That would also need infix precedence.

which means? 🤔

[afs]

s/second/seconds/ to reduce the ambiguity of "the second component of".

[HolgerKnublauch]

@simonstey this will be a great contribution, but the PR has been in draft state and unchanged for several weeks. Do you need input/help to finish it?

[simonstey]

@HolgerKnublauch

@simonstey this will be a great contribution, but the PR has been in draft state and unchanged for several weeks. Do you need input/help to finish it?

whoops, sry.. I'll have this PR merge-ready by next Monday!

[simonstey]

@HolgerKnublauch
I rebased the document and fixed various HTML/merge commit issues. Should be good to go now. fyi, currently I only render the SPARQL functions as a table rather than fully fledged sections.

[HolgerKnublauch]

Thanks a lot, Simon! I have made mostly cosmetic updates to your branch, which are hopefully OK.

We need to decide what to do with aggregates though. They are very different from the other functions as the don't work as in SPARQL: In a SPARQL query you would use them with a variable while in Node Expressions, the processing would work best if they receive another node expression that produces the aggregate values.

This however does not match how the other functions here work, which receive only individual values as arguments, never a list of values. Also, the shnex namespace already contains aggregates.

I suggest we delete the aggregates from our sparql: namespace.

[HolgerKnublauch]

To me it's good enough for now. Further refinements can and will happen in fresh tickets, when needed.