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

Received on Monday, 9 March 2015 00:18:40 UTC