[xquery-talk] [xml-dev] Mistakes made in the design of XQuery 3.1

[daniela florescu]

> 
> 
> Great. Well JSONiq is my tool of choice for dealing with JSON. 
> 
> Can you provide any insights to the graph database landscape. A conversation on xml-dev with Peter Hunsberger has persuaded me that a dual representation (XML for serving data and graph for running algorithms) is probably what I need but I prefer to have some basis for evaluation before jumping in with any particular product.

Unfortunately I cannot help you here. I tried to keep up with the graph languages, but lost it at some
point. Things are moving too fast. 

And unlike NoSQL query languages, where the situation is really pathetic, the graph languages and their implementations
are not that bad, I think. So there are reasonable choices...

Sorry for not helping,
Dana


P.S. 20 years ago I wrote a paper about a graph language (we thought at that time that semi-stuctured data will necessarily be a graph…)
 which kind of influenced the design of SPARQL.
http://www.en.pms.ifi.lmu.de/publications/projektarbeiten/Felix.Weigel/xmlindex/material/fernandez97strudel.pdf <http://www.en.pms.ifi.lmu.de/publications/projektarbeiten/Felix.Weigel/xmlindex/material/fernandez97strudel.pdf>

But of course, this is no help to you, other then intellectual curiosity :-)



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20150530/946fbd86/attachment.html>