Re: SHACL semantics - any alternatives to SPARQL?

Hi Holger
As long as there is an option to express validations using js - like your
example shx:javaScript - without getting into understanding SAPRQL - it
looks good to me.
Anamitra



From:	Holger Knublauch <holger@topquadrant.com>
To:	public-data-shapes-wg@w3.org
Date:	03/12/2015 12:26 AM
Subject:	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
      >>