Just curious did anyone ever tried to build such a thing as describe in this post
Extending the Solution | Stardog. I notice a post on this come back almost annually 
(FYI alot of google search bring us now to the landing page of the doc and not the actual content we were look for)
Indeed they did. See this section of the docs Query Stardog | Stardog Documentation Latest
note quite the same has what is describe in 'Array of values', But did not hurt to ask. Thx
Serge,
Admittedly the array literals are not supported in any meaningful way on the client side but can be very useful within the server itself. If you can describe what you're after, perhaps we can suggest something here.
Regarding the docs, I'm guessing the Google cache hasn't caught up to the new documentation which was release a week or two ago. I'll bring it up internally to see the right folks aware.
Best,
Jess
What part isn't the same? I read the article and the only part in the article that didn't make it in there was the property path stuff. The array itself is a literal but that doesn't mean it can contain elements that aren't literals.
I wrote a couple of dozen functions for working with array literals that you might find useful
I also updated some of the string functions in there to take or return array literals. I also wrote some lambda functions where you can map a function over an array literal and some other stuff like dynamically call a function from a bound variable but I haven't released them yet
Hi Serge,
Extended solutions have not been implemented in their general form described in that blog post (i.e. as recursive structures). There're less disruptive extensions like array literals and path literals which, as Jess pointed out, are mostly for internal use on the server side. Some functions/constructs have been extended to deal with those, eg. if your query generates an array literal, you can UNNEST it into a sequence of solutions or serialise to a meaningful string using the standard str function.
The main reason we haven't done the whole thing was that in 2017 it was mostly perceived a necessary step towards integrating path queries into SPARQL. However eventually we did the Stored Query Service which allows running path queries within larger SPARQL queries, and without extended solutions (as they're described in the post). So far it covers a lot of uses case that have been reported to us.
There're other incremental tickets towards extended solutions, e.g. for UNNESTing paths into a sequence of solutions each representing an edge, so the work is ongoing.
Best,
Pavel
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.