Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rdf4j-dev] Sponsors

Hi Vassil,

Is Ontotext interested in sponsoring or contributing to the Eclipse RDF4J ShaclSail?

The value in the ShaclSail is that it is incremental. You can take a big database with 500 million triples, add/remove a few triples and validation will only take a few milliseconds. There is no other validation engine like this for SHACL, which is why it’s so fast.

There are two very important questions with regards to the SHACL Core.
 - Can everything be implemented with incremental support?
 - Will everything be efficient?

I don’t know if everything in SHACL Core can be implemented with incremental support, however it will be fairly simple to implement any challenging parts without incremental support. This would then be the answer for the second question, not everything will be efficient but this should not stop us from implementing as much as possible efficiently.

The syntax for SHACL is rather bloated yes. I have created SHACL shapes for DCAT, which took a few hours and was hard to check for inconsistencies. For another project one of my coworkers wrote an XSD to SHACL converter, and then we tweaked the SHACL shapes by hand. I am not particularly worried about the terseness of the language. Someone will figure that out if needed.

How does ShEx compare to SHACL? Was it a competing standard that died once SHACL became a recommendation?

For the benchmark:


Here are the results from my benchmark (on a 5 year old macbook pro) against an open source implementation and a commercial database: https://imgur.com/a/uDTMHKk
 - First load the big file into the database (if possible), then time how long the transactions take.
 - “2x add” is transaction 1 & 2
 - “1x update” is transaction 4
 - “1x delete” is transaction 3

Cheers,
Håvard



I am not sure if it will be possible to implement the entire SHACL Core as efficient incremental validation. 


On 9 May 2019, at 17:27, Vassil Momtchev <vassil.momtchev@xxxxxxxxxxxx> wrote:

Hi Håvard,

First of all thanks for the great contribution to the RDF4J community. Honestly, I was very positively surprised by the efficient algorithm implementation. Ontotext is also moving in the direction of RDF Shapes although we took a less direct route i.e. test the Shape language in few solutions before pushing it to GraphDB. I will be happy to share our plans.

Probably the key question is do you believe it's possible to implement an efficient implementation of SHACL Core without additional indexes i.e. relying only that RepositoryConnection.getStatements method has a very efficient implementation?

One of the most difficult parts evaluating ShaclShail was generating a big enough schema in SHACL RDF. It appears overwhelming complex to generate such as a schema compared to Shex [1]. I haven't found any working implementation capable to parse SHACL Compact [2]. I will be happy to hear your experience.

Could you share also the benchmark results comparing RDF4J with a commercial database?

Warm regards,

V.

[1] http://shex.io/

[2] https://w3c.github.io/shacl/shacl-compact-syntax/


On 7.05.19 22:00, Håvard Ottestad wrote:
Hi,

I was wondering if anyone is sponsoring RDF4J development at the moment. Ontotext maybe?

I was benchmarking the ShaclSail on transactional DCAT loads against a big commercial database the other day and it was around 50x faster. Against another open source implementation it was 5000x faster.

However I’m realizing it’s a long road ahead for a full SHACL implementation, and from the looks of it there will be another major refactor/redesign due to some holes in my knowledge of SHACL that pretty much became evident today.

I was talking to CapGemini here in Norway and they were asking about support for the ShaclSail, and I realized it’s pretty much just me, and I have an unrelated full time job. Would be great to get some more support involved.

Håvard
_______________________________________________
rdf4j-dev mailing list
rdf4j-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/rdf4j-dev





Back to the top