Re: [EDITORIAL] Scope examples

On 16/05/2016 9:53, Irene Polikoff wrote:
> In section 2.1 where scopes are explained, after each example data graph,
> there should be a sentence saying which nodes in the example data graph
> are focus nodes for the described shape. Currently, this is done only in
> subsection 2.1.2.

I believe Dimitris' plan was to use color-coding for that purpose, but 
there is no harm in making this more explicit with prose too.

> Also, examples in subsections 2.1.4 through 2.1.6 use
> ex:PropertyScopeExampleShape. Shouldnąt they be
> ex:InversePropertyScopeExampleShape, ex:AllSubjectsScopeExampleShape and
> ex:AllObjectsScopeExampleShape respectively?

Yes, this was an oversight.

On this occasion I also aligned the variable names in the SPARQL queries 
to be closer to the predicate names (which will help with the likely 
renaming to sh:scopeProperty or a similar single property).

All fixed:


> Irene
> On 5/15/16, 1:53 PM, "Karen Coyle" <> wrote:
>> Another solution would be not to name SHACL's class just "class" but to
>> include in the name an indication that it is a specific kind of class. I
>> don't find sh:SHACLClass to be appealing, but it could be shortened to
>> sh:shClass. That would allow us to use "shClass" throughout the document.
>> As I say, it's not lovely, but there is a danger in reusing a common and
>> previously defined term like "class" or "type" or "value." Giving it an
>> unusual name would always alert the reader to think about its meaning.
>> kc
>> On 5/14/16 4:56 AM, Dimitris Kontokostas wrote:
>>> HI Peter,
>>> I updated the terminology according to your comments, let me know if
>>> there are any other issues
>>> The spec should now be consistent with the terms SHACL
>>> instance/subclass/superclass/type
>>> is SHACL necessary in the definition of "SHACL class"?
>>> If yes, do we need to update all class occurrences in the document to
>>> "SHACL class" or only cases like "X is the class of all Y"?
>>> I also took the initiative to update section 1.4 since imo there are no
>>> more issues with RDFS after the new term renaming
>>> 43a763ab4
>>> On Sat, May 14, 2016 at 8:24 AM, RDF Data Shapes Working Group Issue
>>> Tracker < <>> wrote:
>>>      shapes-ISSUE-161 (terminology): [EDITORIAL] terminology fixups
>>>      [SHACL Spec]
>>>      Raised by: Peter Patel-Schneider
>>>      On product: SHACL Spec
>>>      I took a pass over the terminology section.  Initially I made
>>>      in-line edits
>>>      but there were so many that I gave up and just produced a new
>>>      terminology
>>>      section.  This new section is more rigourous, has fewer errors, is
>>> less
>>>      defensive, does not depend on anything outside of the core of
>>> SHACL, and
>>>      does not introduce any terminology excess to that needed to
>>>      uunderstand the
>>>      core of SHACL.
>>>      There is still the open question here as to what makes a node in a
>>>      shapes
>>>      graph be a shape - is it that the node is a SHACL instance of
>>>      sh:Shape in
>>>      the graph or is it that the node has scopes, filters, or
>>> constraints?
>>>      Throughout this document, the following terminology is used.
>>>      Basic RDF Terminology
>>>      This document uses the terms RDF graph, RDF triple, IRI, literal,
>>> blank
>>>      node, node of an RDF graph, RDF term, and subject, predicate, and
>>>      object of
>>>      RDF triples as defined in RDF 1.1 Concepts and Abstract Syntax
>>>      [rdf11-concepts]. SHACL can be used with RDF graphs that are
>>>      obtained by any
>>>      means, e.g. from the file system, HTTP requests, or RDF datasets.
>>>      makes no assumptions about whether a graph contains the triples
>>> that are
>>>      entailed from the graph under any RDF entailment regime.
>>>      Property Values
>>>      The values of (or for) a property p for a node n in an RDF graph
>>> are the
>>>      objects of the triples in the graph that have n as subject and p as
>>>      predicate.  The inverse values of (or for) a property p for a node n
>>>      in an
>>>      RDF graph are the subjects of the triples in the graph that have n
>>>      as object
>>>      and p as predicate.
>>>      SHACL Subclass, SHACL Superclass
>>>      A node Sub in an RDF graph is a SHACL subclass of another node Super
>>>      in the
>>>      graph if there is a sequence of triples in the graph each with
>>> predicate
>>>      rdfs:subClassOf such that the subject of the first triple is Sub,
>>>      the object
>>>      of the last triple is Super, and the object of each triple except
>>>      the last
>>>      is the subject of the next.  If Sub is a SHACL subclass of Super in
>>>      an RDF
>>>      graph then Super is a SHACL superclass of Sub in the graph.
>>>      SHACL Type
>>>      The SHACL types of a node in an RDF graph are its values for
>>>      rdf:type in the
>>>      graph as well as the SHACL superclasses of these values in the
>>> graph.
>>>      SHACL Class
>>>      Nodes in an RDF graph that might be subclasses, superclasses, or
>>>      types of
>>>      nodes in the graph are often referred to as SHACL classes.  SHACL
>>>      makes no
>>>      assumption whether a SHACL class has any particular value for
>>>      rdf:type in
>>>      the graph.
>>>      SHACL Instance
>>>      A node in an RDF graph is a SHACL instance of a SHACL class in the
>>>      graph if
>>>      one of its SHACL types in the graph is the given class.
>>>      Validation, Data graph, Shapes graph
>>>      SHACL defines what it means for an RDF graph, referred to as the
>>>      data graph,
>>>      to validate against an RDF graph containing shapes, referred to as
>>> the
>>>      shapes graph. The result of validation is a validation report
>>> including
>>>      validation results such as informational results, warnings and
>>>      violations.
>>>      Validation may also result in a failure.  Validation of a shapes
>>> graph
>>>      against a data graph involves validating each shape in the shapes
>>> graph
>>>      against the data graph.
>>>      Shape
>>>      A shape is a node in a shapes graph that [A shape is a node in a
>>> shapes
>>>      graph that is a SHACL instance of sh:Shape?.  A shape] provides a
>>>      collection
>>>      of scopes, filters, and constraints that specify how a data graph is
>>>      validated against the shape.  Shapes can also provide non-validating
>>>      information, such as labels and names.
>>>      Validation of a node against a shape
>>>      A node in a data graph is said to validate against a shape if
>>>      validation of
>>>      that node against the shape neither produces any validation results
>>>      that are
>>>      violations nor results in a failure.
>>>      Scope
>>>      A scope is a triple or node in a shapes graph that specfies which
>>>      nodes in a
>>>      data graph are considered in-scope for a shape.  Valdating a shape
>>> in a
>>>      shapes graph involves validating the in-scope nodes for all scopes
>>>      of the
>>>      shape.  SHACL provides several different kinds of scopes, most
>>>      notably all
>>>      SHACL instances in the data graph of a node in the data graph or a
>>> given
>>>      node in the data graph.
>>>      Focus Node
>>>      A node in a data graph that is validated against a shape is called a
>>>      focus
>>>      node.
>>>      Filter
>>>      A filter is a shape in a shapes graph that limits the nodes that are
>>>      validated against the constraints of another shape.  Only those
>>>      nodes that
>>>      validate against all the filters of a shape are validated against
>>> its
>>>      constraints.
>>>      Constraint
>>>      A constraint is a node in a shapes graph that determines how to
>>> validate
>>>      focus nodes based on the values of properties of the node.
>>>      Constraints can,
>>>      for example, require that a focus node be an IRI or that a focus
>>>      node has a
>>>      particular value for a property and also a minumum number of values
>>>      for the
>>>      property.  Constraints that are about a particular property and its
>>>      values
>>>      for the focus node are called property constraints.  Constraints
>>>      that are
>>>      about a particular property and its inverse values for the focus
>>>      node are
>>>      called inverse property constraints.  Constraints can also have
>>>      non-validating properties (such as names and default values) that
>>> do not
>>>      lead to validation results.
>>>      Constraint Component, Parameter
>>>      A constraint component represents a part of a constraint that is
>>>      determined
>>>      by the values one or more properties.  These properties are called
>>>      parameters.  For example, sh:minCount is a parameter for the
>>>      component that
>>>      checks whether the focus node has at least a minimun number of
>>>      values for a
>>>      particular property. Validating a node against a constraint involves
>>>      validating the node against each of its components.
>>> --
>>> Dimitris Kontokostas
>>> Department of Computer Science, University of Leipzig & DBpedia
>>> Association
>>> Projects:,,
>>> Homepage:
>>> Research Group: AKSW/KILT
>> -- 
>> Karen Coyle
>> m: 1-510-435-8234
>> skype: kcoylenet/+1-510-984-3600

Received on Monday, 16 May 2016 00:53:58 UTC