Re: GraphQL and SHACL

As I recall, the main goal was user friendliness. And, yes, the draft proposal was ShEx like, modified to accommodate differences between SHACL and ShEx. 

It was published towards the end of the WG and the consensus was that there was not enough time to review it. I believe it was briefly published as a WG draft, but did not made into into a WG Note https://w3c.github.io/data-shapes/shacl-compact-syntax/ <https://w3c.github.io/data-shapes/shacl-compact-syntax/>. Instead, it is a Community Group report. https://w3c.github.io/shacl/shacl-compact-syntax/ <https://w3c.github.io/shacl/shacl-compact-syntax/>.

We’ve implemented it, have not heard any input with respect to user requirements or satisfaction. 

I wonder if there are any members of the community group that still consider this an important requirement and, if so, would be interested in reviewing/improving, etc.

In the meantime, we’ve been working with GraphQL and now believe it to be quite attractive as a compact/user friendly syntax - because it is so main stream.

Another topic that is of interest to me is building up and sharing libraries of additional constraint components. 

After using SHACL for over a year now, we have gradually build up additional constraint components. I wonder if anyone else have been doing this and how many people would find valuable having a sharable repository of such. I think it would be.

In at least one case, I think either a new core component is needed or a current core component needs to be modified. I am speaking about sh:uniqueLang. I believe it should also address uniqueness of non language tagged values, so that something like below would not be considered valid.

ex:Alice
 ex:label "Alice” ;
        ex:label "Alice2” ;
 ex:label "Alice"@en ;
 ex:label "Alice"@fr .


I don't remember whether we discussed this in the SHACL WG. Maybe we did and some participants argued that there was a workaround with qualified value shapes and the logic would have become too complex otherwise. But, practically speaking, this is inconvenient. 

Irene


> On Jun 20, 2018, at 12:34 PM, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
> 
> I would say that the main feature of a compact syntax is that it is compact.  
> If the desire is for a syntax with maximum user friendliness then call it a
> "user friendly syntax" and don't worry whether it is compact or not.
> 
> 
> If compactness is not the ultimate goal then the ShExC syntax is a worthy
> candidate.  It would have to be slightly modified but it does have most of the
> required constructs.
> 
> 
> The syntax I was referring to is the syntax on page 9 of the tech report
> version of the paper.
> 
> 
> peter
> 
> 
> 
> On 06/20/2018 08:25 AM, Irene Polikoff wrote:
>> Thanks Peter.
>> 
>> I see the “user friendliness” of the compact syntax as its main feature.
>> Would you agree?
>> 
>> I looked at the paper and compact syntax that may be proposed in it was not
>> clear to me. Can you provide some examples?
>> 
>> One issue that I see is that SHACL is very rich and expressive. There is
>> typically a conflict between rich/expressive/comprehensive and simple/easy
>> to use. 
>> 
>> It may be that the compact syntax optimized for ease of learning and use
>> would not support full expressivity. In principle, multiple compact syntaxes
>> could be supported - just like RDF has multiple serializations. However, if
>> it was possible to define a syntax that is very user friendly, compact and
>> has full expressivity, this would be great.
>> 
>> Here is what I mean by the user friendly syntax. 
>> 
>> Below is a pure, not extended GraphQL schema example:
>> 
>> # A user account
>> type User {
>>  name: String!
>>  age: Int             
>>  gender: Gender
>>  purchases: [Purchase]
>> }
>> 
>> type Purchase {
>>  # The internal ID
>>  productId: String!  
>> }
>> 
>> enum Gender {
>>  FEMALE
>>  MALE
>> }
>> The expressivity is less than SHACL - basically, one can describe datatypes
>> and some aspects of cardinality constraints.
>> 
>> However, GraphQL has a “directives” extension point. Using it, we can
>> define, for example,:
>> 
>> # A user account
>> type User {
>>  name: String!
>>  age: Int               @shape(minInclusive: 18)
>>  gender: Gender
>>  purchases: [Purchase]
>> }
>> 
>> type Purchase {
>>  # The internal ID
>>  productId: String!     @shape(minLength: 8, pattern: "[0-9]+")
>> }
>> 
>> enum Gender {
>>  FEMALE
>>  MALE
>> }
>> This would still be valid GraphQL syntax. The extension elements do not
>> break standard GraphQL parsers and tools.
>> 
>> The definition above would then be equivalent to the following SHACL shapes
>> in Turtle:
>> ex:User
>>  a sh:NodeShape ;
>>  rdfs:comment "A user account" ;
>>  sh:property [
>>   sh:path ex:name ;
>>   sh:datatype xsd:string ;
>>   sh:maxCount 1 ;
>>   sh:minCount 1 ;
>>   sh:order 0 ;
>>  ] ;
>>  sh:property [
>>   sh:path ex:age ;
>>   sh:datatype xsd:integer ;
>>   sh:maxCount 1 ;
>>   sh:minInclusive 18 ;
>>   sh:order 1 ;
>>  ] ;
>>  sh:property [
>>   sh:path ex:gender ;
>>   sh:maxCount 1 ;
>>   sh:node ex:Gender ;
>>   sh:order 2 ;
>>  ] ;
>>  sh:property [
>>   sh:path ex:purchases ;
>>   sh:node ex:Purchase ;
>>   sh:order 3 ;
>>  ] .
>> 
>> ex:Purchase
>>  a sh:NodeShape ;
>>  sh:property [
>>   sh:path ex:productId ;
>>   sh:datatype xsd:string ;
>>   sh:description "The internal ID" ;
>>   sh:maxCount 1 ;
>>   sh:minCount 1 ;
>>   sh:minLength 8 ;
>>   sh:pattern "[0-9]+" ;
>>   sh:order 0 ;
>>  ] .
>>  
>> ex:Gender
>>  a sh:NodeShape ;
>>  sh:in ( "FEMALE" "MALE" ) .
>> We have this working already and in use with extensive models that contain
>> thousands of shapes.
>> 
>> Regards,
>> 
>> Irene
>> 
>>> On Jun 19, 2018, at 2:45 PM, Peter F. Patel-Schneider
>>> <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
>>> 
>>> The paper "Semantics and Validation of Recursive SHACL"
>>> by Julien Corman, Juan L. Reutter, and Ognjen Savković has the beginnings
>>> of a compact 
>>> syntax for SHACL.   It looks quite good to me.
>>> 
>>> An extended version of the paper is available at
>>> https://www.inf.unibz.it/krdb/KRDB%20files/tech-reports/KRDB18-01.pdf
>>> 
>>> peter
>>>  
>>> 
>>> 
>>> On 06/19/2018 07:36 AM, Irene Polikoff wrote:
>>>> One of the capabilities for SHACL that is not yet standardized is a compact
>>>> syntax. As part of the WG effort, a draft of the proposed compact syntax was
>>>> developed, but, due to the time constraints, finalizing this work was deemed
>>>> out of scope and to be addressed in the community group.
>>>> 
>>>> In the last 6 months or so we, at TopQuadrant, have been experimenting with
>>>> the use of GraphQL and GraphQL schemas. GraphQL is already widely used and
>>>> interest in it is rapidly growing. We see its design and capabilities as
>>>> well aligned with SHACL, making it possible (among other things) to use
>>>> GraphQL as a compact syntax for SHACL.
>>>> 
>>>> Results of our work will be presented in upcoming
>>>> webinars: https://www.topquadrant.com/graphql-webinar/ this Thursday June
>>>> 21st (9 am EDT) and also next week, Friday, June 29th (4pm EDT) - 2
>>>> timeslots are available to better accommodate different time zones. However,
>>>> both webinars will cover the same content.
>>>> 
>>>> If you are interested in this topic, please join the webinars and provide
>>>> feedback.
>>>> 
>>>> Regards,
>>>> 
>>>> Irene Polikoff
>>> 
>> 
>