Re: SHACL semantics - any alternatives to SPARQL?

Hi Anamitra,

the higher level constraint language currently being proposed looks like 
this (in Turtle):

ex:MyClass
     sh:property [
         sh:predicate ex:myProperty ;
         sh:minCount 1 ;
         sh:valueType ex:MyOtherClass ;
     ] .

Assuming this gets sent to your JavaScript clients in JSON-LD, would 
this be sufficient for your needs, or were you thinking about another 
level of higher level language?

The current SHACL spec also suggests templates, and those can be used to 
build new higher level language terms. For example a client may receive 
something like

ex:MyClass
     sh:property [
         a ex:EmailPropertyConstraint ;
         sh:predicate ex:email ;
     ] .

ex:EmailPropertyConstraint
     a sh:ConstraintTemplate ;
     rdfs:subClassOf sh:PropertyConstraint ;
     sh:sparql "... some SPARQL check" ;
     shx:javaScript "... some JavaScript code that returns constraint 
violations for this..." .

The idea is that the client can look up the JavaScript snippet that it 
needs to execute to validate the condition (via eval()), if it cannot 
handle sh:sparql. Would this capability be useful for your scenarios?

Thanks,
Holger


On 3/12/2015 13:25, Anamitra Bhattacharyya wrote:
>
> Hi
> first and foremost - I apologize for not being able to be present at 
> the WG meetings. I have been trying to catch with the emails as much 
> as possible. Just wanted to pitch in my 2 cents on the discussion 
> regarding SAPRQL as the language for expressing constraints. Our 
> products (Maximo/Tririga) today uses the shape constraints to express 
> validations which are evaluated at the client side (browser based js). 
> We do not delve into SPARQL as that has a steep learning curve for our 
> customers who always end up extending our OOTB resources with extra 
> validations. Customer feedback is very strong in terms of a known 
> scripting language - like javascript to express complex validations. 
> The direction we were moving towards internally was to support a js 
> script to convey the validations that cannot be encapsulated using the 
> normal SHAPE/XSD syntax. I would be inclined to suggest that we should 
> come up with a higher level constraint language and not base that on 
> SPARQ - but keep SPARQL as a viable alternative to that language.
> -- 
> 1. there are cases where the consuming client (a browser) does not 
> have the capability to evaluate a SPARQL expression
> 2. steep learning curve of SPARQL for customers/consultants who end up 
> extending the resource model
> thanks
> Anamitra
>
> Inactive hide details for Holger Knublauch ---03/08/2015 08:19:42 
> PM---Hi Eric, I would not mind publishing a Primer, and it coHolger 
> Knublauch ---03/08/2015 08:19:42 PM---Hi Eric, I would not mind 
> publishing a Primer, and it could even be published
>
> From: Holger Knublauch <holger@topquadrant.com>
> To: public-data-shapes-wg@w3.org
> Date: 03/08/2015 08:19 PM
> Subject: Re: SHACL semantics - any alternatives to SPARQL?
>
> ------------------------------------------------------------------------
>
>
>
> Hi Eric,
>
> I would not mind publishing a Primer, and it could even be published
> before the FPWD of a spec. However, the current Primer has a number of
> issues that I would consider blockers.
>
> When you refactored my original Primer proposal you made some positive
> moves towards a compromise. In particular you suggested a solution to
> the class-vs-shapes debate by using sh:Shape and factoring the Shape
> Selection into its separate mechanism. This is all fine and I have
> applied the same patterns to the SHACL spec.
>
> However, you also made several changes that I had already objected to:
>
> - You completely removed the Template mechanism. However, template
> macros are an approved requirement [1]. Furthermore, nobody seems to be
> against templates in general - I believe the only open issue with
> templates is that Jose suggested to use another language than SPARQL (I
> believe he actually prefers some controlled sub-set of SPARQL).
> Templates are very important to create user-friendly constraint models
> for people who do not know SPARQL, so they need to be mentioned in the
> Primer.
>
> - The choices syntax is unnecessarily different from the rest of the
> syntax. I think I could live with making these a hard-coded type of
> constraint (instead of relying on templates), but I see no need to have
> random new elements such as sh:propertyGroup. Neither should sh:choice
> be directly attached to a Shape.
>
> - The section Associating Data with Shapes ignores the possiblity to
> attach constraints to classes, despite many people requesting this
> capability. In the SHACL spec this is currently left open so that both
> Shapes and Classes can be used, and I would like to see the same
> placeholder solution applied to the Primer until we have resolved the 
> issue.
>
> - Also in that section, you mention some other options about graphs and
> LDP containers, that have not been discussed yet. They should be removed
> for now as they are speculative.
>
> - I will continue to object any attempts to marginalize SPARQL into an
> "extension mechanism". SPARQL is a fundamental part of the language and
> needs to be presented as such, even if certain people don't believe
> SPARQL is important and would go beyond the capabilities of their engines.
>
> - The Primer needs some more ISSUEs to explain where the group has not
> yet found consensus.
>
> - The last sections on Graph Management, Test Case vocabulary and
> comparison with existing technologies could be removed.
>
>
> There are additional details that give a rather unfinished impression of
> the primer, including many JavaScript errors shown by Respec that cause
> the numbering to break, and I am afraid the mouse-over effects of
> JavaScript were introduced too early - I'd rather keep the editing
> process convenient and we can add such nice-to-haves for the final
> version. Likewise, we should remove JSON-LD for now - too much work to
> keep them in synch.
>
> Overall, I'd be willing to go through the current Primer to address some
> of these issues (I still see my name as an Editor), yet I would first
> like to get feedback from the group about whether we want to continue
> with parallel efforts of a Primer and a Spec about essentially the same
> controversial topics. I believe the Primer currently requires more work
> than the Spec towards a FPWD, but this may of course reflect my personal
> bias.
>
> Regards,
> Holger
>
> [1] 
> https://www.w3.org/2014/data-shapes/wiki/Requirements#Constraint_Macros
>
>
> On 3/7/2015 3:23, Eric Prud'hommeaux wrote:
> > * Peter F. Patel-Schneider <pfpschneider@gmail.com> [2015-03-06 
> 08:38-0800]
> >>
> >> On 03/06/2015 07:23 AM, Eric Prud'hommeaux wrote:
> >>> On Mar 6, 2015 7:17 AM, "Peter F. Patel-Schneider"
> >>> <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
> >>> It seems that the working group is supposed to be pushing towards
> >>> publication of a SHACL specification document in the near future. 
>   Does
> >>> anyone have any alternatives to a SPARQL-based semantics for SHACL 
> that
> >>> they would like to put forward?
> >>>
> >>> Yes, I am aware that there are three potential semantics from the 
> Shape
> >>> Expressions community that might be alternatives, but is anyone 
> going to
> >>> champion either the current version of one of these semantics or 
> have a
> >>> modified version available in time for consideration by the working
> >>> group?
> >>>
> >>>> I thought the plan was to publish the primer and to work some more on
> >>>> the semantics before publication.
> >> I thought so too a while ago, and then there was all this debate 
> over the
> >> primer and then the primer appears to have been shelved and this new
> >> document from Holger appeared and there was this apparent push to 
> turn it
> >> into a FPWD.
> >>
> >> Holger's document is listed on the web page, and appears as an 
> editors draft
> >> when viewed.  At F2F2 there was a chair proposal to aim at publishing a
> >> SHACL spec, which was not approved, largely because there were several
> >> comments that the document needed considerable work, but work on the
> >> document has been going forward very quickly so this reason for 
> delay is
> >> mostly overcome.  At the teleconference on 26 February there was a 
> chair
> >> comment that there is a rush in getting a FPWD of the spec out and some
> >> discussion of what needs to be done to the document before FPWD.
> >>
> >> Meanwhile the primer appears to have languished.
> > I'm not sure I agree. I recall having a fairly short list of TODOs in
> > the critical path of FPWD after the F2F:
> >    s/instance/RDF representation of an instance/ per discussion 
> 2015-02-17T21:06:23Z
> >    change the name to SHACL per WG decision
> >      change the namespace to sh:
> >    move the abstract syntax into another doc
> > implemented in
> > 
> https://github.com/w3c/data-shapes/commits/gh-pages/data-shapes-primer/no-class-templates.html
> >
> > I then moved the old LDOM primer to ldom-primer.html and moved
> > no-class-templates to index.html and changed it to and ED to reflect
> > the WG decision.
> >
> >
> >> So it seems to me that there is indeed a rush to get a spec 
> document to FPWD
> >> even as there are disapprovals of major portions of the spec in the
> >> document.  I'm one of the members of the working group that have been
> >> voicing and writing disapprovals, but I'm certainly not the only one.
> >> However, I'm the only one who has presented a worked-out 
> counterproposal
> >>
> >> So if you believe, like I do, that the current spec document is not 
> going in
> >> the right general direction you have the following choices:
> >> 1/ Throw in with me.
> >> 2/ Put forward your own proposal, either for a different spec or 
> for major
> >> changes to the current spec document.
> >> 3/ Try to slow the rush to FPWD for the spec until something better 
> comes along.
> >>
> >> If you are going for 3/ then you should believe that something 
> better will
> >> come along very shortly.  If you are going for 2/ you should 
> realize that at
> >> this point you need something that addresses the vast majority of the
> >> approved and nearly-approved requirements.
> >>
> >> peter
> >>
>
>
>