Re: SHACL semantics - any alternatives to SPARQL?

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



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