<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 30, 2015 at 12:42 PM, daniela florescu <span dir="ltr"><<a href="mailto:dflorescu@me.com" target="_blank">dflorescu@me.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div></div></blockquote><div><br></div><div>Great. Well JSONiq is my tool of choice for dealing with JSON. </div><div><br></div><div>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.</div></div></div></div></div></blockquote><div><br></div></span><div>Unfortunately I cannot help you here. I tried to keep up with the graph languages, but lost it at some</div></div><div>point. Things are moving too fast. </div><div><br></div><div>And unlike NoSQL query languages, where the situation is really pathetic, the graph languages and their implementations</div><div>are not that bad, I think. So there are reasonable choices...</div></div></blockquote><div><br></div><div>Ok back to these NoSql offerings I have a question.</div><div><br></div><div>You are always telling these vendors that their products are not databases they are data stores. Now from that and the limited amount i have read (it is difficult to continue reading beyond the point where you know this is not a product you want to use) it sounds like these products are little more than glorified VSAM files.</div><div><br></div><div>I get why SQL is not an appropriate basis for a language for these data stores but I don't yet see how we make the leap from XQuery being a language for particular types of semi-structured data to it being the basis of a query language suitable for semi-structured data in principle, unless you are talking in very broad terms about the features such a query language should have and what principles should guide it's design.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div><br></div><div>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…)</div><div> which kind of influenced the design of SPARQL.</div><div><a href="http://www.en.pms.ifi.lmu.de/publications/projektarbeiten/Felix.Weigel/xmlindex/material/fernandez97strudel.pdf" target="_blank">http://www.en.pms.ifi.lmu.de/publications/projektarbeiten/Felix.Weigel/xmlindex/material/fernandez97strudel.pdf</a></div><div><br></div><div>But of course, this is no help to you, other then intellectual curiosity :-)</div><div><br></div></div></blockquote><div><br></div><div>People who are not intellectually curious end up writing blogs about why you should not do what they did. Then again they also get the kudos of being  invited to give talks about their cock-ups to other people who are not intellectually curious but want to learn from the bitter experience of others.</div><div><br></div><div>But  yes i will try and give it a read.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></div></div>