Re: ANN: Clojure library

On 26/03/2017 4:28, Gregg Kellogg wrote:
>> On Mar 25, 2017, at 8:17 AM, Dietrich Schulten <ds@escalon.de 
>> <mailto: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
>>>>
>>>> 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.

Hi Gregg,

could you clarify why you believe that ShEx is "much easier" to 
implement than SHACL, and how it can cover the same use cases as SHACL 
along the way?

For an example SHACL implementation, see http://shacl.org/playground

Note that unlike ShEx (where the language is limited to what has been 
hard-coded), SHACL is extensible.

>>>
>>> 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
>>>
>>
>> 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.

SHACL-SPARQL does not depend on SPARQL EXISTS. Even if some corner-cases 
of SPARQL EXISTS are not well-defined in the current version of SPARQL, 
this would affect anyone using SPARQL, so I guess right now the whole 
semantic web stack is "broken" as long as it uses SPARQL somewhere.

>
> 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.

Well this would require a much longer explanation about the history of 
the Data Shapes WG. Let's better not go there. It suffices to say that 
the group was heterogeneous, with different sub-groups who had different 
agendas. This made the "chemistry" quite challenging from the beginning. 
At some stage the chair had to make a decision against ShEx and in favor 
of a mix between IBM Resource Shapes and SPIN because the majority of WG 
members did not believe it was the best choice moving forward. At that 
stage, most ShEx proponents became rather passive in the WG. Then two 
key participants had to retire from the group, yet others have meanwhile 
joined. There have been a number of people supporting SHACL in public 
recently, see

     https://www.w3.org/2014/data-shapes/wiki/Endorsements

and several implementations have emerged

https://www.w3.org/2014/data-shapes/wiki/Main_Page#Implementations

I believe the division between SHACL and ShEx is an unfortunate 
historical outcome, but it is not too late yet to do something about it, 
e.g. by adding a compact syntax to SHACL. Differences for JSON-LD users 
are IMHO marginal.

HTH
Holger



>
> 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 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
> [2] http://shexspec.github.io/shexTest/reports/
>