Re: shapes-ISSUE-94 (hsolbrig): Should RDF syntax requirements be separated from SHACL semantics [SHACL Spec]

Harold,

The spec only defines the RDF syntax for SHACL. Other syntaxes are
possible, but their semantics must be given by translation in the RDF
syntax, i.e. an alternate syntax must not define any new semantics.

The spec interleaves syntax and semantics. This is good from a
readability viewpoint. However, the complete set of syntax rules is
not easy to extract, so anyone writing a syntax validator would have
trouble. At some point, it would be helpful to include a syntax
summary in the spec, maybe as a normative appendix.

Personally, I also think it would be useful to have a separate formal
semantics document. However, few people would read it. Nevertheless,
it would prove to us that the semantics were well-defined.

-- Arthur

On Thu, Sep 24, 2015 at 4:54 PM, RDF Data Shapes Working Group Issue
Tracker <sysbot+tracker@w3.org> wrote:
> shapes-ISSUE-94 (hsolbrig): Should RDF syntax requirements be separated from SHACL semantics [SHACL Spec]
>
> http://www.w3.org/2014/data-shapes/track/issues/94
>
> Raised by: Harold Solbrig
> On product: SHACL Spec
>
> The SHACL specification doesn't currently differentiate the core semantics requirements for any SHACL implementation for the RDF specific syntax.  As an example, sh:allowedValues identifies a set of RDF Terms that constrain the possible targets of a given predicate.  The fact that this is a set and the fact that they must be RDF Terms would appear to be true no matter what syntax is used.  The next sentence in the document states that this set must be represented as "well-formed instances of rdf:List", which would make sense in (some) RDF representations of SHACL, but would have no meaning in other situations.
>
> Would it make sense to create a style or some sort of identifier in the specification that would allow readers to differentiate universal requirements from those that are only applicable in RDF syntax?
>
>
>

Received on Sunday, 11 October 2015 23:37:34 UTC