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

on poor wording and loose terminology for prefix handling

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Thu, 29 Sep 2016 09:00:10 -0700
To: "public-rdf-shapes@w3.org" <public-rdf-shapes@w3.org>
Message-ID: <a028b894-dac7-9369-0a39-d392ecf532ea@gmail.com>
I took a look at the new prefix rules for SHACL in Section 5.  I had a very
hard time understanding what is going on becuase of poor wording and loose
terminology in parts of the section (or maybe it is loose terminology
because of poor wording in the section).  In summary, it appears that the
prefix rules are a poor description of an implementation of SHACL.  The
rules mandate a particular method for processing SHACL documents, ruling out
other, potentially better, methods.  Both prefix handling and its
description need to be changed significantly.

I have only looked closely at a small portion of Section 5.  There are
undoubtedly other places in the rest of the section and the rest of the
document where wording and terminology are also unacceptable.  The working
group needs to take a very close look at the entire document to find and fix
these.



>From Section 5.1:

"The SPARQL queries linked to a constraint via sh:select must be string
literals that can be parsed into legal SPARQL 1.1 queries of the query form
SELECT after they have been treated with the prefix handling rules outlined
later."

This is quite loose and not even actually correct.  Instead, acceptable
values of sh:select for SHACL constraints are string literals which are
mapped into legal SPARQL 1.1 queries of the query form SELECT by the prefix
insertion mapping.  If a SHACL processor attempts to determine the SPARQL
query result for a value of sh:select which does not thus map into a legal
SPARQL 1.1 query it MUST signal a failure (or whatever - I didn't look to
see exactly what the wording is for this sort of situation).

Section 5.1 mixes the example up with definitional parts of SHACL.  These
need to be teased apart so that the normative force of the section is
obvious.

>From Section 5.2:

"Before parsing the values of sh:select (or similar properties such as
sh:ask), a SHACL Full processor must prepend PREFIX declarations"

So first a SHACL processor must prepend the PREFIX declarations and then it
must parse the result.  This mandates a particular mode of operation for
SHACL processors and also isn't really correct either.  Instead all that
this section should be doing is determining what prefix declarations to use
and how they affect values of sh:select.  It is up to SHACL implementers to
determine whether they actually want to prepend and then parse (and then
evaluate) or to use some other method of obtaining the result sets needed
during validation.

"for all namespace prefixes that are linked to the subject of the sh:select
triple via the property sh:prefixes in the current shapes graph."

Linked appears to be used in some very loose manner here.  Instead what is
needed is a firm definition of how to find the appropriate sh:declare
triples and what to do with their values.  Something along the lines of "The
SHACL prefix declarations for a SPARQL-based constraint are its values for
the path sh:prefixes/owl:import*." is probably correct.

Then SHACL prefix declarations need a firm definition, probably something
along the lines of "A SHACL prefix declaration is a blank node or IRI in a
shapes graph that has precisely one value for sh:prefix, which is a literal
with datatype xsd:string, and precisely one value for sh:namespace, which is a
literal with datatype xsd:anyURI.  The SPARQL prefix declaration for a SHACL
prefix declaration is the string ``PREFIX <prefix>: <namespace> '' where <prefix>
is the lexical form of the SHACL prefix declaration's value for sh:prefix
and <namespace> is the lexical form of the SHACL prefix declaration's value
for sh:namespace.  The SPARQL prefix for a SPARQL-based constraint consists
of the SPARQL prefix declarations for its SHACL prefix declarations
concatenated together in some undetermined order."

Also needed is something like: "A SPARQL-based constraint SHOULD NOT have
two different SHACL prefix declarations with the same value for sh:prefix.
SPARQL processors MAY signal a failure or warning for such SPARQL-based
constraints."

Then the SHACL prefix insertion mapping is defined as "The SHACL prefix
insertion mapping for SPARQL-based constraints takes a SPARQL-based constraint
and prepends its SPARQL prefix to the lexical form of its value for sh:select."

The changes fix up some of the poor wording and firm up some of the loose
terminology in about three paragraphs of Section 5.  They will have to be
re-integrated with the neighbouring bits of the section, which may require
further rewriting.

Peter F. Patel-Schneider
Nuance Communications
Received on Thursday, 29 September 2016 16:00:44 UTC

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