I think it’s important to the original question to point out that a problem is likely to includes mixtures of different types of data. BaseX has an SQL module and Marklogic includes modules for RDF and you can write extensions and use http to integrate external systems in various XML database systems.

 

For the skeptical person that we are pitching XQuery and BaseX to it’s probably best to be prepared to describe a solution that isn’t unnaturally forcing XML to fit as the solution for every problem.

 

Kendall

 

From: Graydon Saunders <graydonish@gmail.com>
Date: Saturday, February 25, 2017 at 5:09 PM
To: Kendall Shaw <kendall.shaw@workday.com>
Cc: BaseX <basex-talk@mailman.uni-konstanz.de>
Subject: Re: [basex-talk] Somewhat unusual question

 

Hi Kendal --

 

If you don't stick to attributes, it's not hard to represent that kind of relationship graph in XML:

 

<people>

    <person name="cindy">

        <knows>karen</knows>

    </person>

    <person name="karen">

        <knows>linda</knows>

    </person>

    <person name="linda">

        <knows>sarah</knows>

    </person>

    <person name="sarah">

        <knows>wendy</knows>

    </person>

    <person name="wendy">

        <knows>cindy</knows>

    </person>

</people>

 

This way you can have a lot of <knows> elements (edges in the relationship graph) for an individual.  The XML graph and the represented graph don't match structurally and you'd have to go through and build maps or something in XQuery to manipulate the represented graph, but writing a function to get everybody who knows Cindy within a certain number of edges wouldn't be difficult.  (Taking off the "certain number of edges" obliges you to write some sort of cycle detection mechanism, which is harder and presumably the people behind SPARQL have already done so.)

 

So not quite as syntactically compact but I don't think XML is obviously unsuitable for "represent an arbitrary graph".  You have to pick your XML vocabulary carefully but "arbitrary graph" and "carefully" go naturally together.

 

-- Graydon

 

On Sat, Feb 25, 2017 at 7:42 PM, Kendall Shaw <kendall.shaw@workday.com> wrote:

On 2/25/17, 12:55 PM, "Liam R. E. Quin" <liam@w3.org> wrote:

    On Sat, 2017-02-25 at 10:02 +0000, Kendall Shaw wrote:
    > It’s interesting to me to know what sorts of applications seem like
    > they would be a good match for XQuery’s data model but turned out not
    > to be in some case.

    I agree that's interesting - I'm afraid I have more experience with
    what didn't work in SQL and did work with a forest store, probably
    because I don't often encounter people whose projects didn't fit with
    XML-related technologies. How do we find them?

 Aside from things like the 100,000 sensors scenario that you described, the friends example might be a case that is in the same area that XML makes sense.

With XPath having special support for hierarchical data, matching XML’s notion of element hierarchy, it’s perfect for data like:

<totem-pole>
<person name=”cindy”>
  <person name=”karen”>
    <person name=”linda”>
      <person name=”sarah”>
        <person name=”wendy”/>
      </person>
    </person>
  </person>
</person>
</totem-pole>

So you can us $person//*/@name to get cindy’s sub-friends. Also, the document is constrained to be well-formed by the rules of XML document types, based on elements having only 1 parent. But, friends aren’t constrained to have only have 1 super-friend. And poor Wendy gets no sub-friends.

A less restricted graph representation can represent that where hierarchy doesn’t have special status:

@prefix : <people#> .
:cindy :name “cindy” ; :knows :karen .
:karen :name “karen” ; :knows :linda .
:linda :name “linda” ; :knows :sarah .
:sarah :name “sarah” ; :knows :wendy .
:wendy :name “wendy” :knows :cindy .

And with SPARQL, having special support for graph traversal, matching RDF’s notion of connected edges, it’s perfect for data like above.

So, you can use ?p :knows/:name ?name to get cindy’s friend’s friend’s friend’s friend’s etc. Also, Wendy gets to have a friend too.

Representing something similar in XML, ignoring RDF XML which makes it even more complicated:

<friends>
  <person name=”cindy” knows=”karen”/>
  <person name=”karen” knows=”linda”/>
  <person name=”linda” knows=”sarah”/>
  <person name=”sarah” knows=”wendy”/>
  <person name=”wendy”/>
</friends>

The rules of XML document types don’t include special support for arbitrary attribute relationships, in the way that element hierarchy does have special status. You can write XQuery to navigate that data, but it’s not a simple expression and doesn’t use ancestor/descendant axes so maybe it’s not the best choice for the data.

The other way around, when most of the data is hierarchical it’s harder to use something like SPARQL with RDF than XPath with XML. And RDF is not necessarily the best representation for graphs where nodes and edges both have attributes.

Kendall