Re: ANN: Clojure library

> On Mar 25, 2017, at 4:23 PM, Holger Knublauch <holger@topquadrant.com> wrote:
> 
> 
> 
> 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 <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?

It was not fair of my to say that it is “much easier” to implement, because I have not attempted an implementation of SHACL. All I can say is that my initial implementation of ShEx took about a week, which seemed like a small effort. At least by observation on the data-shapes mailing list, there seem to be a number of complexities involved with SHACL, but having not looked at it in detail, I can’t really say.

The primary use case I was aware of that ShEx did not cover was to determine cardinality of language-tagged literals to have only one value per language. Support for this will be in 2.0. Otherwise, I believe it covers substantially the same use cases, but obviously differs in details.

> For an example SHACL implementation, see http://shacl.org/playground <http://shacl.org/playground>
> 
> Note that unlike ShEx (where the language is limited to what has been hard-coded), SHACL is extensible.

ShEx does have extensibility features, but these are mostly missing from 2.0, so that is indeed a fair point. The main thing here would be logical restrictions, say that the birthdate of a parent must be prior to the birthdate of a child. These are in scope for ShEx post 2.0.

I was not trying to denigrate SHACL, but forward the assertion that ShEx is a light-weight shapes mechanism that is achieving broad support and is very much an alternative to be considered.

Gregg

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