Re: ANN: Clojure library

> On Mar 25, 2017, at 8:17 AM, Dietrich Schulten <ds@escalon.de> wrote:
> 
> Am 29.01.2017 um 20:27 schrieb Gregg Kellogg:
>>> On Jan 29, 2017, at 9:42 AM, Markus Lanthaler <markus.lanthaler@gmx.net <mailto:markus.lanthaler@gmx.net>> wrote:
>>> 
>>> On 27 Jan 2017 at 15:14, Asbjørn Ulsberg wrote:
>>>> 2017-01-27 12:30 GMT+01:00 Antonio Garrote Hernández <antoniogarrote@gmail.com <mailto:antoniogarrote@gmail.com>>:
>>>> 
>>>>> I just wanted to let you know about a Clojure library for Hydra APIs I have
>>>>> been working on:
>>>>> 
>>>>> https://github.com/antoniogarrote/levanzo <https://github.com/antoniogarrote/levanzo>
>>> 
>>> Fantastic work Antonio! Thanks for sharing
>>> 
>>> 
>>>>> It also supports validation based on the declarative information in the API
>>>>> and mock data generation. I hope to add additional support for SHACL so it
>>>>> can offer more expressive validations.
>>>> 
>>>> Sounds like a good plan. I think it has been discussed before that
>>>> SHACL should become an integrated part of Hydra, so experience in how
>>>> to combine Hydra and SHACL is very welcome. :)
>>> 
>>> +1
>> 
>> Note that the ShEx [1] JSON variant (ShExJ) was just changed to JSON-LD, and there are a number of implementations. ShEx handles the same use cases as SHACL, but makes implementation much easier.
>> 
>> There are a couple of places that shape matching could come in handy:
>> 
>> * For validating the Hydra documentation
>> * As a way to specify the expected shape of a Hydra Operation
>>   * Client-side to formulate the operation
>>   * Server-side to validate the operation
>> * For performing before/after analysis of the target. (LD-Patch could also come in handy here).
>> 
>> Gregg
>> 
>> [1] https://shexspec.github.io/spec <https://shexspec.github.io/spec>
>> 
> 
> Very interesting, I'll have a look and try to find out where ShEx statements would go in a hydra document.
> 
> @Gregg can you comment a bit about the relationship between SHACL and ShEx? Just two competing specs?

They both came out of the W3C RDF Validation Workshop about 3 years ago [1]. ShEx was the brain-child of Eric Prud’hommeaux and is based on a syntax for describing RDF shapes, that is not (or was not) RDF itself. ShEx defines semantics for navigating and constraining RDF Graphs using it’s own logic. Since the first version, it’s evolved considerably to provide a more solid theory for describing how matching statements can be partitioned (at least theoretically) to satisfy shape constraints. The 2.0 release is imminent, and uses ShExJ as a kind of abstract shape representation. As this uses JSON-LD with a ShEx vocabulary, this allows a ShEx schema to be described in RDF. There is an undescribed transformation from an RDF Graph into ShExJ, which is largely implementable using JSON-LD Framing. Although there is nothing concrete, we believe that any ShEx schema can be transformed into a SHACL constraint.

SHACL takes a more RDF Vocabulary-centric view, where there is not really an independent syntax, but rather a vocabulary that allows constraints to be described in RDF. As I understand it, SHACLE Core processors implement their own logic to determine graph conformance, similar to the way a ShEx processor would. SHACL-SPARQL processors operate by transforming the constraints into SPARQL queries. This dependes on some EXISTS logic, which is broken in SPARQL 1.1, and there is a CG sporadically working on improvements to EXISTS to support the necessary logic.

I’ve focused my time on ShEx, as I have received a number of requests from my community of developers for adding this to the Ruby toolchain. Indeed, I understand that a number of participants have dropped out of the RDF Data Shapes WG and are instead looking at ShEx.

If both go to completion, SHACL will benefit from being a W3C Recommendation, while ShEx is a Community Group (much like Hydra), so will act as more of a community standard. Who’s to say where it will go from there.

There are about 4 different implementations of ShEx, with varying stages of conformance, as evidenced by an interim implementation report [2].

Being JSON-LD (and RDF), a ShEx Schema could potentially be embedded within Hydra documentation, or more likely, specific shapes could be referenced to an external Schema. ShEx takes a map of graph nodes to shapes and returns a report describing the conformance of each node to the given shape, so this could happen fairly easily, IMO.

> BTW, if someone reads the primer and wonders why they didn't write it in ShExJ, there is a radio button somewhere at the bottom of the  section https://shexspec.github.io/primer/index.html#validation <https://shexspec.github.io/primer/index.html#validation> which allows you to switch representations. Or press the J key on your keyboard :-)
> 
> Best,
> Dietrich

Gregg

[1] https://www.w3.org/2012/12/rdf-val/report <https://www.w3.org/2012/12/rdf-val/report>
[2] http://shexspec.github.io/shexTest/reports/ <http://shexspec.github.io/shexTest/reports/>