Commons RDF?

[ajs6f]

This is a very neat project, and I am thinking about using it as the basis of a validation module for Apache Jena. I see that you are recommending using RDF4J but you do have support for Jena. Would you be interested in a PR that puts shex-java over Apache Commons RDF (which supports Jena, RDF4J, and several other implementations?

[jdusart]

Thanks. Yes, there is a small support for Jena. You have the class fr.inria.lille.shexjava.graph.JenaGraph that allow to use Jena Model. This will convert your Jena IRI, Literal and BNode when asked to RDF4J IRI, Literal and BNode that are used in the implementation. Yes, I will consider using Commons RDF for the next release.

[ajs6f]

Great! I've started the work here.

Unsurprisingly, it's kind of a large changeset, since a lot of code must be touched to use new types. Currently I have:

Tests run: 4280, Failures: 18, Errors: 3, Skipped: 0

although the number of tests-in-error, for some strange reason, seems to vary occasionally. I don't pretend to understand the test framework very well, so that remains to be investigated. All of the failing tests are in TestShExCParserShExJSerializer.

WIP! :) I can open a PR at any point if we want to use Github's commenting and discussion tools.

There are a few design issues:

• Commons RDF is not the full-featured framework that RDF4J or Jena are. So for validating XML Schema datatypes, I am still dropping through to RDF4J. I don't think that's a terrible thing, though. It would be nice to be able to deploy shex-java with no dependency on RDF4J, but I don't know if that's worth the cost of discarding tried and true code for XS datatype validation in favor of something new and unproven.
• Commons RDF's parsing API is still experimental, so I am using RDF4J directly in those places where parsing is needed. Of course, Jena could be used as well, but the point is that parsing isn't going through Commons RDF yet. That's an "upstream" issue, so to speak. Solidifying parsing in Commons RDF could take a while.
• There is still confusion amongst different methods of labeling blank nodes. I don't think Commons RDF can really abstract that away. Some frameworks are able to make guarantees that go beyond those mandated by the recommendation.
• I am providing the Commons RDF RDF object (much like the RDF4J ValueFactory) as a static instance. This could be a little more flexible, perhaps using ServiceLoader or the like.

Please let me know if anything sounds or looks horrible or like I'm going completely wrong or off. I don't pretend for a moment to any deep knowledge of ShEx, so all comments welcome!

[ajs6f]

One other note-- I'm trying to do a very literal "translation" to start with. In other words, although the Commons RDF API is different not just in name but also in functionality from RDF4J, I'm trying not to use any more of the differences than are absolutely necessary. If and when this work seems acceptable, I can continue on and make use of some of the differences, mostly to shorten the code here and there.

[jdusart]

Great work but before going any further, this week I look at it and have started a new branch commons which is the passage to dev to commons. This pass most of the tests. Also be careful when you launch the tests, because there are some problems or disagreement with some tests in it (we are currently looking to solve those problems), the implementation is not returning a test failure when a test fails to not create problems with maven build. You need to look at the trace of the maven test run to know the tests that it's failing.

For the implementation:

• I have manage to get ride of the RDF4J dependencies for now except for the class DatatypeUtil in the util package and for parsing.
  • For parsing, I choosed to not use the experimental part of Commons and keep using RDF4J.
  • For blank node, how it is implemented depend of the implementation of the RDF Factory.
  • For now the solution I used to deal with RDF factory is to pass it as an arguments.

[ajs6f]

Yes, I saw that test failures don't fail the test, so to speak. So... should I abandon my branch? I have no desire to waste time redoing work.

[ajs6f]

As to the two branches, it sounds like we made the same decisions, which is generally a good sign!

[jdusart]

I also did in my branch some small code reorganization, so I prefer that we keep mine.

[ajs6f]

I will close my PR. As I wrote, my concern is to reuse this module with Jena, so please close this issue when you merge your branch so that I will know that I can move forward. Thanks!

[ajs6f]

Ah, just realized that I never issued the PR, so nothing to close.

[jdusart]

I have just released on maven the version 1.1a with better support for commonsRDF.

[ajs6f]

Great, thanks! I will try to build up a jena-validator module around it.