Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rdf4j-dev] SHACL sail refactor

Hi Jeen,

Very good points. I agree now that it’s best to keep it in the graph. Would also be great to load shacl rules from file or similar when instantiating the sail, it could work the same way under the hood with a named graph in the base sail.

I rebased my branch on develop.

Håvard

> On 8 Apr 2018, at 01:56, Jeen Broekstra <jeen.broekstra@xxxxxxxxx> wrote:
> 
> 
> 
> On 06/04/18 04:18, Håvard Ottestad wrote:
>> Hi Jeen,
>> Thanks for helping out :) The Code isn’t very clean no :(
>> Some basic concepts that I’ve worked on:
>> - A need to convert the shacl rules from rdf into a java model with
>> methods that represent the de-normalized rules. Eg. the AST.
>> - Based on what has changed in a transaction, we need to generate a
>> plan for how to get data to validate. These are the plan nodes. And
>> the tracking is done with the two memory stores in the connection
>> (first in two hashsets )
>> - A need to transport data and track where it came from, so we can
>> tell the user that they broke a shacl rule because of some triples
>> added or removed. This is done by the Tuple class.
> 
> All sounds very good.
> 
>> I don’t want to mix data with rules. Regular SQL databases don’t
>> store their schemas inside the users database. The SHACL sail should
>> support multiple options for loading in rules and options for
>> updating rules. But updating rules should be done explicitly with an
>> explicit command (also a good reason for not having them inside the
>> userdata). Updating rules is not currently supported.
> 
> +1 on supporting multiple options for loading in rules.
> 
> What I prefer is that at the level of the API, the rules are exposed as
> a 'virtual' named graph, e.g. 'rdf4j:Shapes'. The idea would be that the
> rules can be examined and updated through normal SPARQL / Repository API
> operations that explicitly use this named graph identifier.
> However, the ShaclSail would ensure that this named graph is not
> included in the default graph, so "normal" queries/updates won't access
> the rules data. This means we still have separation between rules and data.
> 
> There's several advantages to this approach: first of all access and manipulation is available via the Repository API directly, using generic methods, so it won't involve any user code that needs to call special custom methods at the level of the ShaclSail (this is an important design consideration - user code should not be required to do any operations at the level of the Sail beyond initial config/initialization). It also gives us multiple upload/modification options for the rules, for free. Supporting rule updates becomes easier, as the ShaclSail can detect changes to the rules in a named graph more easily than if they are offered via a separate repository object.
> 
> Also note that in this setup, the decision on whether the rules data
> lives in the same physical store as the user data is up to the Sail itself.
> 
>> And, btw. I do have a branch where I’m working on supporting
>> sh:datatype, and someone else was working on some cleanup and support
>> for string based restrictions. Can I maybe merge my branch into
>> yours, it’s mostly done, and it also contains cleanup of some of the
>> tests?
> 
> I haven't really made as much progress on my changes as I expected (I
> blame jet lag), so it might in fact be easier if I just wait until you're ready to merge and then pull the updates into my branch. Were you working from master or are you treating this as feature dev work?
> 
> Cheers,
> 
> Jeen
> _______________________________________________
> rdf4j-dev mailing list
> rdf4j-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/rdf4j-dev



Back to the top