bblfish / banana-rdf

Banana RDF

Hi there 👋

• 🔭 I’m currently working on a number of project to enable authentication and access control on the Web, following Solid protocol ideas, as part of the Solid Control now continuing into the Solid Wallet project.
• 1 page CV/resumé
• 👯 Full social network in my foaf rdf profile
• 😄 Pronouns: The Babelfish
• ⚡ Fun fact: I developed the BabelFish machine translation service at AltaVista in the 1990s.

banana-rdf's Issues

serialisers output diverge given a base

Different serialisers give very different results when given a base.
This shows up in inconsistent results returned by SerialisationTestSuite "graphs with relative URIs" tests.

The reference graph consists of the three triples

<http://www.w3.org/2001/sw/RDFCore/ntriples/> 
     <http://purl.org/dc/elements/1.1/creator> "Dave Beckett", "Art Barstow" ;
     <http://purl.org/dc/elements/1.1/publisher> <http://www.w3.org/> .

Call the graph consisting of those triples referenceGraph.
Writing it out to a string with the following base

writer.asString(referenceGraph, Url("http://www.w3.org/2001/sw/RDFCore/"))

gives very different results depending on the serialisers.

The Jena Turtle Serialiser refers to the publisher using the relative URL /

<ntriples/>  <http://purl.org/dc/elements/1.1/creator>
                "Art Barstow" , "Dave Beckett" ;
        <http://purl.org/dc/elements/1.1/publisher>
                </> .

The Jena Json-LD serialized (Titanium) refers to the publisher using the
path relative URL ../../../

{
    "@id": "ntriples/",
    "http://purl.org/dc/elements/1.1/publisher": {
        "@id": "../../../"
    },
    "http://purl.org/dc/elements/1.1/creator": [
        "Art Barstow",
        "Dave Beckett"
    ]
}

and using the Jena RDF/XML serialisation, the publisher is referred to by its absolute URL.

<rdf:RDF
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:dc="http://purl.org/dc/elements/1.1/">
  <rdf:Description rdf:about="ntriples/">
    <dc:publisher rdf:resource="http://www.w3.org/"/>
    <dc:creator>Art Barstow</dc:creator>
    <dc:creator>Dave Beckett</dc:creator>
  </rdf:Description>
</rdf:RDF>

These are just differences between the parsers for Jena. (currently, RDF4J is on hold because of a dotty issue lampepfl/dotty#16408, but it is unlikely that it gives us more uniformity )

There may be ways the behaviour could be tuned, but the best way to tune it is unclear.

The problem is that our tests try to deserialise the resulting relative graph strings with a different base. Given the above, this results in very different graphs. The idea was to test what happens if one moves a graph with relative URLs to a different base. But the publisher URL remains the same in the RDF/XML case, whereas that changes in the other two serialisations. Furthermore, in the json-ld case, the new base would have to ensure it is at least three levels deep to allow the reference ../../../ to refer to something. The Turtle root / would not need that.

Publish to Maven Central

Until this new version of banana-rdf is unified with the mainline, it would be great if we could publish it to Maven central.
The group id can be com.github.bblfish which is very easy to request to Sonatype.
EDIT: I just noticed that you already own the groupid.

json-ld and other parsers for banana-rdf

Writing a parser using banana-rdf would allow allow it to immediately work efficient with Jena, rdf4j, JS RDF Libs, etc...

What is needed are really streaming async parsers that can transform data on the fly from streams of bits to streams of triples quads or graphs so that one uses the least amount of memory possible.

Some links for an asynchronous json-ld parser.

1. json-ld specs are available from here https://json-ld.org/
2. fs2-data https://fs2-data.gnieh.org/documentation/ has streaming json parsers I think
3. banana-rdf for scala 3 can help abstract all the types so that the parser can immediately work with all implementations https://github.com/bblfish/banana-rdf

Other parsers would be

• NTriples: would be the simplest, and be a goot small project to get going
• NQuads: would also be simple, and bring in the notion of named graphs.
• rdf/xml using an existing rdf/xml parser but plugging it into the fs2-data xml-parser -- after checking its properties of course
• Turtle, Trig
• N3 would perhaps be the most difficult

List of RDF Mime types