- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Thu, 19 May 2016 07:10:18 -0700
- To: public-data-shapes-wg@w3.org
On 5/18/16 11:09 PM, Dimitris Kontokostas wrote:
>
>
> On Thu, May 19, 2016 at 1:15 AM, Peter F. Patel-Schneider
> <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
>
> Here is a proposed partial reply to Tom Baker. It depends on some
> changes
> that have not been done to the SHACL specification.
>
> peter
>
> Date: Sun, 1 May 2016 16:40:21 +0200
> From: Thomas Baker <tom@tombaker.org <mailto:tom@tombaker.org>>
> To: RDF Shapes <public-rdf-shapes@w3.org
> <mailto:public-rdf-shapes@w3.org>>
> >
> > Comments on
> >
> > Shapes Constraint Language (SHACL)
> > Editors Draft 29 April 2016
> > http://w3c.github.io/data-shapes/shacl/
> >
> > Some context: I have followed this activity since participating
> in the workshop
> > on RDF validation in 2013 [1]. The activity seemed like it might
> achieve the
> > goals pursued a decade ago with the DCMI Working Draft,
> Description Set Profile
> > Constraint Language [2]. I have tried to keep up with the
> excellent work by
> > Karen Coyle, Antoine Isaac, Hugo Manguinhas, Thomas Hartmann, and
> others on
> > comparing the emerging SHACL specification to requirements that have
> > accumulated over the years in the Dublin Core community.
> >
> > There is alot to like in SHACL but I must confess that each time
> I tried to
> > actually read the specification I found myself getting stuck at
> the same
> > places. I'd set it aside, assuming that the issues would shake
> out. Many
> > months later, however, I find the same sticking points,
> unchanged. This time I
> > pressed on through the introduction to Section 2.1.
> >
> > These comments convey my thoughts while reading the text and end
> with some
> > suggestions. I have made no effort to catch up on discussion in
> the relevant
> > mailing lists [4,5], so please forgive me if I simply cover
> issues here that
> > are already well-understood.
> >
> > Abstract
> >
> > First sentence (also first sentence of Introduction):
> >
> > "SHACL is a language for describing and constraining the
> contents of RDF
> > graphs"
> >
> > So I ask myself: If an RDF graph is an immutable set of
> triples, in what
> > sense can it be "constrained"? If an RDF graph is a
> description with a
> > meaning determined by RDF semantics, what does it mean for that
> _description_
> > to be "described"? Surely SHACL is not meant to somehow limit the
> > RDF-semantic meaning of an RDF graph, which would make no
> sense, but then
> > what does mean "constraining" mean? Surely the specification of a
> > "constraint language" should start by defining "constraint".
>
> 1: Change: Replace "constraining" by "validating" whereever possible
> in the
> document.
>
>
> One problem with this is that C in SHACL stands for Constraint and if we
> eliminate the term constraint in the document the name becomes irrelevant.
> Especially in the abstract we should, imho, have all the SHACL terms
> (Shapes, Constraint, Language).
>
There's a difference between being a "constraint language" which is a
language to describe constraints, and "constraining" or "validating"
which are actions. For the most part I do not think that the SHACL
document should be talking about constraining or validating - it should
be about the language. SHACL does not constrain, although it does
describe constraints and desired validation outcomes. It may be
necessary, at least for some aspects of SHACL, to describe the desired
outcomes when using the language, but that isn't an action being
performed by SHACL, it is the expectation on implementations using
SHACL. (Some of this could be bracketed as "conformance requirements".)
Throughout the document there are too many verbs that shouldn't be there
in the spec for a descriptive language. Once we settle on some of the
bigger design issues, I could go through and edit these out.
-kc
>
> 2: Change in abstract and introduction: SHACL is a language for
> validating
> whether RDF graphs meet certain conditions.
>
> > Further on, one finds that the "constraint language" actually
> has nothing to
> > do with somehow constraining RDF graphs and everything to do
> with describing
> > an instance of the class "shape", which can be used with a
> process for
> > determining whether a given RDF graph conforms to the set of
> constraints
> > described in that shape ("validation"). In the Abstract,
> however, validation
> > is mentioned only in passing ("can be used to communicate
> information about
> > data structures... generate or validate data, or drive user
> interfaces").
> >
> > The Abstract concludes with an unsettling reference to the
> "underlying
> > semantics" of SHACL. We already have RDF semantics. Will this
> document
> > define another?
>
> 3: Change: Use "SHACL" to differentiate SHACL versions of
> terminology from RDF
> and RDFS versions throughout the document.
>
> > 1. Introduction
> >
> > "This document defines what it means for an RDF graph... to
> conform to a
> > graph containing SHACL shapes"
> >
> > An improvement over the Abstract.
>
> 4: Change to:
>
> This document defines the SHACL Shapes Constraint Language, a
> language for
> validating RDF graphs against a set of conditions. These conditions are
> provided as shapes and other constructs expressed in the form of an RDF
> graph. RDF graphs that are used in this manner are called "shapes
> graphs" in
> SHACL and the RDF graphs that are validated against a shapes graph are
> called "data graphs". As SHACL shape graphs are used to validate
> that data
> graphs satisfy a set of conditions they can also be viewed as a
> description
> of the data graphs that do satisfy these conditions.
>
> > 1.2. SHACL example
> >
> > "A shapes graph containing shape definitions and other
> information that can
> > be utilized to determine what validation is to be done"
> >
> > The wording is odd. How about:
> >
> > "A shapes graph, which describes a set of constraints, can be
> used to
> > determine whether a given data graph conforms to the
> constraints."
>
> 5: Change to:
>
> A shapes graph contains shapes and other information to determine
> whether a data graph validates aganinst the shapes graph.
>
> > Up to this point, has the text actually said that SHACL shape
> graphs are
> > expressed in RDF? The Document Outline does say that examples
> are expressed
> > in Turtle syntax, which strongly implies RDF. But that SHACL
> shape graphs
> > are expressed in RDF is actually not obvious for anyone who
> knows that SPARQL
> > also expresses shape-like constructs for matching against RDF
> data, and that
> > SPARQL constructs are not themselves expressed in RDF.
>
> > (As an aside, readers of RDF 1.1 Turtle will find instances
> with prefixed
> > names in lowercase, whereas in the SHACL spec the prefixed
> names are in
> > uppercase. A sentence about the naming conventions used in
> this document
> > could make this explicit.)
> >
> > Section 1.2 continues:
> >
> > "ex:IssueShape... [has constraints that apply]... to a
> (transitive)
> > subclass of ex:Issue following rdf:subClassOf triples"
> >
> > Hmm - nothing in the spec has yet hinted that the process of
> validating a
> > data graph against a shape graph will _require_ additional,
> out-of-band
> > information such as schema definitions.
>
> 6: *NEEDS WORK*
>
> > 1.3. Relationship between SHACL and RDF
> >
> > "SHACL uses RDF and RDFS vocabulary... and concepts... [but]
> SHACL does not
> > always use this vocabulary or these concepts in exactly the
> way that they
> > are formally defined in RDF and RDFS."
> >
> > Hang on, so SHACL does _not_ use RDF/S vocabulary as defined by
> the RDF/S
> > specs?? It is jarring to read this in a W3C rec-track
> specification. How is
> > this not a show-stopper?
> >
> > One then learns that SHACL validation is about more than
> matching an
> > immutable data graph against an immutable shapes graph.
> Apparently it
> > involves the prior creation of an _expanded_ data graph through
> selective
> > materialization of inferred triples.
>
> 7: The only materialization-like notion in SHACL is default value
> types. This
> notion is being revised and may be done away with.
>
> > The notion of "SHACL processors" having (selectively) to
> support inferencing
> > goes far beyond just defining a vocabulary for describing a
> shape and a
> > process for evaluating that shape against a data graph. It
> implies a
> > software application with SHACL-specific features and an
> inferencing style
> > that is SHACL-specific -- both of which, to my way of thinking,
> should be
> > completely orthogonal to the language specification, which
> could quite
> > reasonably focus on just the vocabulary and validation algorithm.
>
> 8: SHACL shapes are written in RDF and some constructs in SHACL are
> grouped by
> using rdf:type and rdfs:subClassOf triples. The document will be
> changed to
> use SHACL-specific vocabulary showing that there is no need for
> inferencing
> beyond SPARQL paths, in particular rdf:type/rdfs:subClassOf*
>
> > If, as the spec points out, "SHACL implementations may operate
> on RDF graphs
> > that include entailments", couldn't the SHACL spec be helpfully
> simplified by
> > leaving the materialization of inferred triples out of scope
> entirely -- as
> > something done in a pre-processing phase, perhaps according to
> a few
> > well-known patterns as described in a separate specification?
>
> 9: This could have been done but the working group did not want to
> depend on
> any external materialization of entailed triples. SHACL thus works
> on any RDF
> graph.
>
> > The section ends with very puzzling definitions for "subclass",
> "type", and
> > "instance" -- "A node is an instance of a class if one of its
> types is the
> > given class"?? -- but I press on, hoping the next section will
> bring some
> > clarity...
>
> 10: This section will be eliminated in favor of SHACL-specific terms.
>
> > 2. Shapes
> >
> > The first paragraph says:
> >
> > "Shape scopes define the selection criteria"
> >
> > but then Figure 1 says:
> >
> > "Scope selects focus nodes"
> >
> > If a shape is just a graph (or part of a shapes graph), then
> surely that
> > graph cannot actually perform a action, like "selects", as if
> executed like a
> > Java method. Figure 1 also talks about filter shapes that
> "refine" or
> > "eliminate" and constraints that "produce". Talking about
> graphs as agents
> > is deeply confusing.
> >
> > "Class-based scopes define the scope as the set of all
> instances of a
> > class."
> >
> > Okay, yes... classes have extensions... after all, RDF Schema
> 1.1 says that
> > "Associated with each class is a set, called the class
> extension of the
> > class, which is the set of the instances of the class" [3].
> But what does
> > this have to do with defining the set of focus nodes for a
> shape? The scope
> > of a shape is _not_ a specific data graph but the set of all
> instances of a
> > class in the world?
>
> 11: *NEEDS WORK*
>
> > I stop reading.
> >
> > Summary and suggestions
> >
> > The spec looks quite nice on the surface but the explanation is
> conceptually
> > muddled. Would it not be simpler and clearer to define a SHACL
> where, to
> > paraphrase the 2008 DSP specification [2], "the fundamental usage
> model for a
> > [shape] is to examine whether a [data graph] matches the
> [shape]"? Everything
> > else could be out of scope. Some suggestions:
> >
> > 1. Define "constraint" up-front.
>
> Shapes are discussed early. Constraints are introduced in the new
> section
> on terminology.
>
> > 2. If a shape is described in RDF, say so early on, then avoid
> implying that a
> > SHACL shape is based on any semantics other than RDF semantics.
>
> See change 4: above.
>
> > 3. Come up with better names than 'subclass', 'superclass',
> 'type', and
> > 'instance' for whatever it is that is being described. Anyone
> familiar with
> > classes and instances in RDF -- or classes and instances in
> OOP -- will
> > surely be led astray by yet another completely different re-use of
> > terminology that only _seems_ familiar. Repurposing these
> well-worn terms
> > actually gets in the way of understanding.
>
> *NEEDS TO BE DONE* Most of these have been eliminated in favor of
> "SHACL type".
>
> > 4. Move anything about materializing additional triples as a
> pre-processing
> > step -- even sub-class relationships -- into a separate
> document specifically
> > for implementation advice, such as a primer. In other words,
> split out all
> > references to inferencing from the SHACL language itself. To
> keep the
> language
> > specification clear, an immutable data graph need only be
> validated
> against an
> > immutable shape graph, full stop. Anything else can be moved
> elsewhere.
>
> *NEEDS TO BE DONE*
>
> > 5. Move Sections 6 through 11 into a separate document or
> primer. Far better
> > to put this into its own shorter, focused specification than
> tack it onto
> > specification that is already much too long -- 108 pages, had
> I printed
> it out.
>
> *NEEDS TO BE DONE*
>
> > Simpler, clearer specs stand a correspondingly greater chance of
> actually being
> > read -- and used.
> >
> > Tom
> >
> > [1]
> https://www.w3.org/blog/SW/2013/10/04/w3c-workshop-report-rdf-validation-practical-assurances-for-quality-rdf-data/
> > [2] http://dublincore.org/documents/dc-dsp/
> > [3] https://www.w3.org/TR/rdf-schema/#ch_classes
> > [4] https://lists.w3.org/Archives/Public/public-rdf-shapes/
> > [5] https://lists.w3.org/Archives/Public/public-data-shapes-wg/
> >
> > --
> > Tom Baker <tom@tombaker.org <mailto:tom@tombaker.org>>
>
>
>
> Date: Thu, 5 May 2016 10:15:11 +0200
> From: Thomas Baker <tom@tombaker.org <mailto:tom@tombaker.org>>
> To: RDF Shapes <public-rdf-shapes@w3.org
> <mailto:public-rdf-shapes@w3.org>>
>
> > More comments on SHACL [1], Editor's Draft 29 April 2016
> > http://w3c.github.io/data-shapes/shacl/
> >
> > I posted a previous batch of comments on 1 May [1] but have
> learned a few
> > things since then. I remain unsure what the specification really
> means in some
> > respects, so the following reflects what I think the
> specification "really"
> > means -- what I infer it to mean -- with some suggestions on how
> the spec
> > could help the reader by articulating some key assumptions up-front.
> >
> > 1. SHACL provides a vocabulary for describing shapes and a simple
> > algorithm for "validating" an arbitrary graph of RDF data
> (Data Graph)
> > against an RDF description of data shapes (Shapes Graph).
>
> See 4:
>
> > 2. The SHACL validation algorithm checks the conformance of
> triples in
> > the Data Graph to "constraints" described in the Shapes Graph.
>
> See 4:
>
> > 3. Validation evaluates a target Data Graph at the level of its
> abstract
> > syntax. In accordance with RDF 1.1 Concepts and Abstract
> Syntax [1],
> > RDF abstract syntax consists of triples, or subject and object
> nodes
> > connected with predicates, with nodes that may be IRIs, blanks, or
> > datatyped literals. The SHACL spec's use of "focus nodes" fits
> with
> > the use of "node" in rdf11-concepts [2].
>
> SHACL works on RDF graphs, which is the abstract syntax of RDF, but
> "RDF graphs" is a better name for this. There is wording in the new
> terminology section that does defer to [2] for terminology from there.
>
> > 4. In accordance with the Closed-World Assumption (CWA), the
> validation
> > algorithm limits itself to matching constraint patterns, as
> described in
> > the Shapes Graph, against the abstract-syntactic components of
> the triples
> > actually asserted in target Data Graph, with no further
> interpretation of
> > the Data Graph or inferencing based on its formal semantics.
>
> More care is now taken to say that SHACL works on data graphs directly.
>
> > 5. A Shapes Graph is expressed in RDF. Even though the primary
> use of
> > a Shapes Graph is for CWA-based validation, it should be noted
> that the
> > semantics of the Shapes Graph itself, as of any other
> expression in RDF,
> > follows the Open-World Assumption (OWA).
>
> Shapes graphs in SHACL are viewed as syntactic constructs, where the
> OWA and
> CWA assumptions are not relevant. SHACL does determine whether some
> syntactic constructs are valid by using chains of rdfs:subClassOf
> triples,
> but this again only looks at the triples that are in the RDF graph.
> Thus
> SHACL does not depend on any open-world notions.
>
> > 6. The inherently open-world meaning of the Shapes Graph,
> however, does not
> > seem to be of practical consequence for its use in CWA-based
> validation --
> > unless, perhaps, one were to construct or augment a Shapes
> Graph with
> inferred
> > triples -- with the caveat that shapes graphs could
> potentially pollute
> > "real" data by adding meaning that is not intended to be
> interpreted as
> > real data, e.g., as when the practical hack of using a class
> IRI to name a
> > shape were followed (Section 2.1.2.1, "Implicit Class Scopes").
>
> The scopes of a shape are determined only by looking at the triples
> in the
> shapes graph. SHACL does not depend on the addition of any triples to
> either the shapes graph or the data graph, even for shapes that are also
> SHACL instances of rdfs:Class.
>
> *NEED TO RENAME "implicit" to something else*
>
> > 7. A Shapes Graph may specify a potential set of "focus nodes" as
> the "scope"
> > of validation in the Data Graph. A Shapes Graph may also
> specify a
> potential
> > set of "focus nodes" to be dropped out of the validation scope
> ("filtered").
> > Potential focus nodes may or may not match actual nodes in the
> Data Graph.
>
> The discussion of shapes, scopes, and filters has been revised
> considerably.
> *NEED TO DO THIS*
>
> > 8. Validation based on closed-world assumptions applies to the
> relationship
> > between constraints (as described the Shapes Graph) and
> triples in the data
> > graph viewed at the level of their RDF abstract-syntactic
> components
> > (e.g., the "focus nodes").
>
> *TO DO*
>
> > Note: An earlier iteration of these comments was posted on the
> DC-ARCHITECTURE
> > [3]. The resulting thread drew out some additional comments and
> insights that
> > could be of interest to members of Data Shapes.
>
> The working group may take these extra comments into account.
>
> > [1]
> https://lists.w3.org/Archives/Public/public-rdf-shapes/2016May/0000.html
> > [2] https://www.w3.org/TR/rdf11-concepts/
> > [3]
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1605&L=dc-architecture&P=3148
> >
> >
> ----------------------------------------------------------------------
> > Discussion
> >
> > Because SHACL is expressed in RDF, like it or not, a Shapes Graph is
> > interpreted according to OWA. Since the design decision was made
> to express
> > the Shapes Graph in RDF, and not in a completely different syntax
> -- as in the
> > case of SPARQL or, for that matter, DCMI's DSP -- the native OWA
> interpretation
> > of a Shapes Graph cannot be papered over, ignored, or otherwise
> contradicted.
>
> SHACL views the shapes graph as an RDF graph, i.e., a set of
> triples. As
> all that counts is this set of triples, the OWA is not relevant.
> Even if
> this were not the case, there is nothing in the SHACL specification
> that is
> concerned with whether something that is not stated in the shapes
> graph, or
> in the data graph, is false or not.
>
> > The design choice of expressing Shapes Graphs in RDF does
> somewhat limit SHACL,
> > in certain respects, compared to SPARQL or DSP. In SPARQL, for
> example,
> > `rdfs:subClassOf*` is interpreted as referring to the transitive
> closure of
> > `rdfs:subClassOf`; the asterisk is a sort of syntactic sugar, a
> convenience
> > notation, that triggers specific inferences. As there is no
> equivalent way to
> > express `rdfs:subClassOf*` in RDFS, there is no way to say that
> > `rdfs:subClassOf` actually _means_ the transitive closure
> without, in effect,
> > arbitrarily overriding its global semantics.
>
> The RDFS semantics implies that rdfs:subClassOf is transitive so any
> discussion of classes in RDFS has to take this into account. As
> SHACL is
> only concerned with RDF graphs as sets of triples it does not depend
> on the
> RDFS semantics when it talks about SHACL types (and SHACL subclass,
> superclass, and instance) so these are defined as using the transitive
> closure of rdfs:subClassOf triples. The SHACL specification takes
> care to
> use "SHACL" to distinguish these notions from their RDF and RDFS
> versions.
>
> *NEEDS TO BE DONE*
>
> > Perhaps this is why the SHACL spec says that "SHACL does not
> always use this
> > vocabulary or these concepts in exactly the way that they are
> formally defined
> > in RDF and RDFS" (Section 1.3) -- a notion which gratuitously
> sets SHACL at
> > odds with W3C Semantic Web standards.
>
> *TO DO*
>
> > One could perhaps sidestep the issue by dropping _all_
> consideration of
> > inferencing from the normative SHACL specification; saying only
> that there may
> > be a need for inferencing in a pre-processing phase; then
> discussing those
> > pre-processing options in a separate guidance document. Putting
> inferencing
> > out of scope would make the SHACL spec simpler, clearer, and shorter.
>
> Instead of depending on pre-processing SHACL does its own
> determination here.
>
> > Abstract syntax issues
> >
> > Because SHACL is viewing RDF data graphs through a closed-world
> lens, the
> > meaning of the graph is beside the point -- just as the meaning
> of a graph is
> > beside the point with SPARQL. A SHACL Shapes Graph is validated
> against a Data
> > Graph at the level of the abstract syntax of the Data Graph.
> According to RDF
> > 1.1 Concepts and Abstract Syntax, RDF graphs are sets of
> subject-predicate-
> > object triples, where the elements may be IRIs, blank nodes, or
> datatyped
> > literals [1].
>
> This is made more clear in the current version of the specification.
>
> *NEEDS TO BE DONE*
>
> > Note that at the level of their abstract syntax, RDF Graphs have
> no "classes"
> > and no "instances"! A search in rdf11-concepts [1] for the words
> "instance" or
> > "class" will find no mention of either one, anywhere in the spec.
>
> This is why SHACL needs to define its own terminology in the new
> terminology
> section.
>
> > Confusingly, the SHACL spec makes reference to "instances",
> "classes", or
> > "instances of classes" in the Data Graph, viewing the Data Graph
> through a
> > semantic lens. Coining a new SHACL-specific notion of "instance"
> (and "class",
> > etc) next to the existing notions of RDF "instance" and OO
> "instance" make
> > SHACL particularly hard to grok. At the end of Section 1.3, for
> example, the
> > definition for "instance" starts off by saying:
> >
> > "A node is an instance of a class..."
> >
> > which I take to mean:
> >
> > "A node [in the Data Graph] is an instance of a class..."
>
> *TO DO*
>
> > By comparison, the SPARQL spec specifies a SPARQL-specific syntax
> to express
> > triple patterns composed of variables and RDF-abstract-syntactic
> things such as
> > IRIs and Literals. SPARQL itself does not "understand" that
> something is a
> > class or an instance -- it simply supports the formation of
> triple patterns and
> > leaves it to Primers and other usage guides to express queries,
> informally, in
> > semantic terms (e.g., "What data is stored about instances of
> class X?") This
> > separation of concerns makes the SPARQL specification much easier to
> > understand. It is worth noting that DCMI's Description Set
> Profile Constraint
> > Language [3] also defines its own syntax.
>
> *TO DO*
>
> > As an aside, it is unclear to me why it is even necessary for the
> SHACL spec to
> > redefine an already-loaded, overdetermined term such as "class"
> to refer to a
> > set of what one might call "type-matched focus nodes". If the
> intention is to
> > make SHACL more understandable to people who are unfamiliar with
> RDF, this
> > should be done not in the formal spec but in a primer or
> tutorial, where an
> > explanation can be customized for a specific audience, such as
> programmers.
>
> *TO DO*
>
> > A year ago, it was proposed that an abstract syntax be developed
> for SHACL [4].
> > There was little discussion and the issue remains open but
> neglected. Since
> > SHACL is natively expressed in RDF, its abstract syntax is in
> effect the
> > abstract syntax for RDF. It is not clear to me whether this is
> actually a good
> > idea. If a Shapes Graph only exists to be used in a closed-world
> process
> > validating a Data Graph, what is the specific advantage of
> expressing it in
> > RDF? Might a proper abstract syntax for SHACL, based on its own
> BNF, etc,
> > further focus and clarify the SHACL language? On the other hand,
> I see no
> > specific reasons why SHACL should _not_ use RDF to express shapes
> graphs as it
> > does -- provided that the spec (or a primer) point out any
> potential pitfalls,
> > as touched on above.
>
> *TO DO*
>
> > [1] https://www.w3.org/TR/rdf11-concepts/
> > [2] https://www.w3.org/TR/rdf11-concepts/#data-model
> > [3] http://dublincore.org/documents/dc-dsp/
> > [4] https://www.w3.org/2014/data-shapes/track/issues/52
> >
> >
> > --
> > Tom Baker <tom@tombaker.org <mailto:tom@tombaker.org>>
>
>
>
>
> --
> Dimitris Kontokostas
> Department of Computer Science, University of Leipzig & DBpedia Association
> Projects: http://dbpedia.org, http://rdfunit.aksw.org,
> http://aligned-project.eu
> Homepage: http://aksw.org/DimitrisKontokostas
> Research Group: AKSW/KILT http://aksw.org/Groups/KILT
>
--
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600
Received on Thursday, 19 May 2016 14:10:47 UTC