| [rdf4j-dev] SHACL sail refactor |
Havard, others,I'm currently taking a closer look at the SHACL Sail design and I think there's of lot of things that we can refactor/streamline:
1. The initialization interface is overly complex: we shouldn't need to provide a separate Repository object with the shapes data to the sail - it should just use a dedicated named graph for this purpose. Issue logged as https://github.com/eclipse/rdf4j-storage/issues/67 .
2. A lot of functionality (factories for shape objects, generating plans for each shape, etc) is currently embedded inside the AST objects. I can live with this (though I would have preferred a better separation of concerns) but it explicitly relies on supplying SailRepository objects, SailRepositoryConnections, etc. where there's no need. This needs to be rigorously simplified. As far as I can tell we effectively keep all the shape data in memory during validation so why stick it in a (in memory) repository whenever we pass it to a Shape AST object? We should just use the Model API here IMHO.
I've started work on the first issue but I've quickly found that the second is closely related. I know you're currently also working on the SHACL Sail, but I think it's urgent that we get the basic design clean before adding more functionality. Are you ok with me doing some rigorous refactoring and putting up a PR (hopefully mid next week)? I'm working from master under the assumption that we get to break an API in a patch release if that API was explicitly marked as EXPERIMENTAL :)
Jeen