Re: Progress toward making RDF easier?

On Fri, Feb 21, 2020 at 09:12:36AM +0000, Richard Light wrote:
> On 21/02/2020 08:29, Martynas Jusevičius wrote:
> 
> Hi,
> 
> On Fri, Feb 21, 2020 at 9:26 AM Thomas Francart
> <[email protected]><mailto:[email protected]> wrote:
> 
> 
> 
> I read at https://us2ts.org/program-easier-rdf a proposal to deprecate RDF/XML. This syntax has a major advantage : it can be generated using XSLT from source XML files. This ability to bridge XML and RDF is also key in some projects.
> 
> 
> 
> I was about to write exactly the same thing. RDF/XML is a crucial
> bridge to/from the XML stack.
> 
> To put it more generally, an XML serialization of RDF graphs is a crucial bridge to/from the XML stack. You could make an argument (under the 'simplify RDF' heading) for a less clever XML serialization which simply represents nodes and arcs for what they are. I did this when faced with the job of generating multiple RDF serializations from an XML source.  Once I had my 'simple RDF XML', I could write a single generic XSLT transform for each serialization required.  I couldn't begin to do that, starting from RDF/XML.

Jonathan Robie built a general RDF/XML parser in XQuery in <https://www.w3.org/XML/2002/08/robie.syntacticweb.html>. This enabled XPath to navigate all of the isomorphisms in RDF/XML's nested structure.

At the other end of the spectrum, jjc et all created TriX <https://www.hpl.hp.com/techreports/2004/HPL-2004-56.pdf> which represents TriG:
[[
  <https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Skepticism/Green_Cheese_Model_of_Lunar_Composition> {
    <https://www.wikidata.org/wiki/Q405> # the moon
    <https://www.wikidata.org/wiki/Property:P527> # has part
    <https://www.wikidata.org/wiki/Q3546121> # type of Cheese
  }
]]
in XML:
[[
  <TriX xmlns="http://www.w3.org/2004/03/trix/trix-1/">
    <graph>
      <uri>https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Skepticism/Green_Cheese_Model_of_Lunar_Composition</uri>
      <triple>
        <uri></uri>
        <uri>https://www.wikidata.org/wiki/Q405</uri> <!-- the moon -->
        <uri>https://www.wikidata.org/wiki/Property:P527</uri> <!-- has part -->
        <uri>https://www.wikidata.org/wiki/Q3546121</uri> <!-- type of Cheese -->
      </triple>
    </graph>
  </TriX>
]]

> Also, as you imply, it's not just about generation of Linked Data: it's also about consumption. What I'm working on right now is an XSLT transform which uses the XSLT document() function to query a Linked Data resource and add lat/long coordinates to my source (XML) data.

I'm not sure you actually want a flat structure like TriX for XSLT translations to consumable alternatives. While RDF/XML is highly idiosyncratic (it was trying to be like what RDFa is today and consequently dances around the heuristics of 2000-era browsers), the nesting makes transformations to ther nested structures a lot easier. Adding a layer of associativity to the lat/long example above, imagine a simple movement from one place to another expressed in JSON:

{ "@type": "...Movement",
  "from": { "lat": "12N", "long": "34W" },
  "to": { "lat": "56S", "long": "78E" }
}

This XSLT target will be considerably easier if you start with a nested RDF/XML than if you start with flattened TriX (or flattened RDF/XML for that matter).

If you want convenience, you want nesting; if you want completeness at the cost of more complex XSLT, you want a flat structure.


> Richard
> 
> 
> 
> .
> 
> 
> --
> Richard Light