W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > August 2016

Re: comments on SHACL Core Abstract Syntax and Semantics

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Mon, 29 Aug 2016 08:21:22 -0700
To: Eric Prud'hommeaux <eric@w3.org>, Martynas Jusevičius <martynas@graphity.org>
Cc: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, public-rdf-shapes@w3.org, James Anderson <james@dydra.com>
Message-ID: <1301797d-93ee-f299-0b1b-8ba2254d5764@kcoyle.net>


On 8/29/16 7:49 AM, Eric Prud'hommeaux wrote:
> * Martynas Jusevičius <martynas@graphity.org> [2016-08-28 22:49+0200]
>> I am wondering about the notation:
>> https://www.w3.org/TR/shacl-abstract-syntax/#notation
>>
>> Is this some notation created specifically for this document? Or this
>> some standard/common notation reused? If not, why not?
>
> It's basically scala case classes plus disjunction on the type. This
> seemed like a sweet spot because it provides
> - named parameters.
> - sets and lists.
>
> An equivalent Z notation would be a slightly more wordy because it
> would require extra primitives for every set or disjunction so e.g.:
>
> Shape := label:IRI|BNode, targets:Set[Target], filters:Set[Shape], constraints:Set[Test]
>
> would be something like:
>
>   ┌─Shape─────────────
>   │ label:IRIorBNode
>   │ targets:ℙ Target
>   │ filters:ℙ Shape
>   │ constraints:ℙ Test
>   └───────────────────
>   IRIorBNode ::= { x | x ∊ IRI ∨ x ∊ BNode }

I prefer that we NOT use a notation that requires 1) an extended 
character set and 2) symbols that many people will not understand. At 
most, people in my community MAY read EBNF, but mostly they are coders, 
and the advantage of this notation is that it uses conventions that will 
either be familiar to those folks or easy to learn. Not so the example 
immediately above. It's a question of audience, and I would like us to 
address a general audience here, not a specialist one.

kc

>
> This is chatty, but it could use that to add definitions for the
> interesting functions:
>
>   valid(Shape) ⇔ ¬excludedBy(filters) ∧ valid(constraints)
>
> I'm happy to adapt to another notation if you have one you prefer.
>
>
>> I am working on a specification that attempts to define semantics for
>> SPARQL-backed Linked Data, so it would be good to know. Currently we
>> use denotational semantics:
>> https://en.wikipedia.org/wiki/Denotational_semantics
>
> I think a denotational semantics would use terms defined in an abstract syntax in order to
>
>
>> On Sat, Aug 27, 2016 at 8:55 PM, Peter F. Patel-Schneider
>> <pfpschneider@gmail.com> wrote:
>>> Yes I mean the English language descriptions of the meanings of the various
>>> constructs.   This provides a semantics for SHACL, albeit an informal one.
>>>
>>> Examples of syntax are examples of syntax, i.e., not semantic.  Providing an
>>> informal description of these examples is semantics of a sort, but saying what
>>> an example means is generally considered to not to have any normative force.
>>>
>>> peter
>>>
>>>
>>> On 08/27/2016 08:46 AM, Karen Coyle wrote:
>>>> Thank you, Peter, these are great comments. We'll incorporate as many as we
>>>> can into the next version of the document.
>>>>
>>>> I do have a question about your use of the term "semantics" because it may be
>>>> different from mine. By "semantics" do you mean the English-language
>>>> explanations of the syntax? And if so, does that also include the examples?
>>>>
>>>> Thanks again,
>>>> kc
>>>>
>>>> On 8/26/16 11:09 AM, Peter F. Patel-Schneider wrote:
>>>>> Some comments on SHACL Core Abstract Syntax and Semantics first public
>>>>> working draft 25 August 2016 at https://www.w3.org/TR/shacl-abstract-syntax/
>>>>>
>>>>>
>>>>> There is a discrepancy between the title and abstract of the document.  The
>>>>> title includes semantics but the abstract only talks about syntax.  The
>>>>> document should be clear at the beginning about what it covers.
>>>>>
>>>>> The body of the document does talk about the semantics of SHACL.  There is
>>>>> already a semantics provided for SHACL in https://www.w3.org/TR/shacl/.
>>>>> There does not appear to be any reason to have two different documents that
>>>>> provide a semantics for SHACL, even with one of them being non-normative.
>>>>> As there is no reason for a second version of the semantics of SHACL it
>>>>> needs to be removed from this document.
>>>>>
>>>>> The document appears to provide an abstract syntax for SHACL.  The abstract
>>>>> and title say "core SHACL" but there is no discussion in the body of the
>>>>> document as to just what is being covered.  If the document is just covering
>>>>> the core of SHACL it needs to qualify what it is doing throughout the body
>>>>> of the document.
>>>>>
>>>>> The document does not even cover all of the core of SHACL.  For example, it
>>>>> does not provide for severities or any of the non-validating aspects of
>>>>> SHACL shapes.  This needs to be remedied or explained.
>>>>>
>>>>> The document uses "SHACL instance graph".  This is probably referring to a
>>>>> shapes graph and thus probably needs to be changed.  Instance graphs,
>>>>> however, contain schemas, which are not defined for SHACL.
>>>>>
>>>>> The document uses RDF Semantics as its source of definitions for some RDF
>>>>> notation.  It would be better to reference RDF 1.1 Concepts and Abstract
>>>>> Syntax where possible.
>>>>>
>>>>>
>>>>> I think that the document in its current form has negative utility.  The
>>>>> abstract syntax does not correspond to any coherent part of SHCL.  The
>>>>> semantics is just going to be a competitor to the informal and formal
>>>>> semantics in https://www.w3.org/TR/shacl/.  If the semantics stuff was
>>>>> removed and the abstract syntax actually corrsponded to the SHACL core
>>>>> syntax then there might be some small utility for the document.
>>>>>
>>>>>
>>>>> Peter F. Patel-Schneider
>>>>> Nuance Communications
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600
Received on Monday, 29 August 2016 15:21:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:43 UTC