Re: SHACL semantics - any alternatives to SPARQL?

* Holger Knublauch <holger@topquadrant.com> [2015-03-09 10:17+1000]
> 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

I'd be very surprised if all the folks present at that vote understood
that it would be used as evidence that we specifically need SPIN
templates. At the time, I recall folks saying "well, perhaps ShEx is a
'template' language..." It seems likely that it would have met with
objection had it explicitly read "SPIN templates".


> 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 document no-class-templates.html was very explicit about factoring
out templates and classes from the rest of 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.

I'm not sure what the counter-proposal is. How would I say that
there was a choice between (foaf:name) OR (foaf:givenName AND
foaf:familyName)?


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

We discussed this extensively during the F2F:
  http://www.w3.org/2015/02/18-shapes-minutes.html#item03
  http://www.w3.org/2015/02/18-shapes-minutes.html#item04
and agreed that Richard would work out a semantics for punning:
[[
Start from Eric's Revised LDOM proposal, and explore ways to
combine shapes and classes such as punning
]]
  http://www.w3.org/2015/02/18-shapes-minutes.html#resolution01


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

http://w3c.github.io/data-shapes/data-shapes-primer/#associations
currently says
[[
SHACL defines two predicates, sh:nodeShape and sh:classShape. The
former asserts that a particular node in some graph conforms to a
specific shape. The latter asserts that every node of some type
conforms to a specific shape. It is expected that different
communities will develop many more associations, much as the WSDL
community created an association between input and output documents
and an XML schema which described them.
]]
I believe it was the group's intent that there be other uses of
SHACL. Do you find the text misleading of our intentions?


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

I believe the strategy at the F2F was to separate the SPARQL
and templates bits out, as evidenced by the support for the
no-class-templates primer.


> - The Primer needs some more ISSUEs to explain where the group has
> not yet found consensus.

There are a few in there already, some with switches to select
rendering between different proposals.


> - The last sections on Graph Management, Test Case vocabulary and
> comparison with existing technologies could be removed.

done

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

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Monday, 9 March 2015 18:25:18 UTC