W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > May 2016

[EDITORIAL] Scope examples

From: Irene Polikoff <irene@topquadrant.com>
Date: Sun, 15 May 2016 19:53:59 -0400
To: <public-data-shapes-wg@w3.org>
Message-ID: <D35E82CD.9F2DC%irene@topquadrant.com>
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.

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?

Irene



On 5/15/16, 1:53 PM, "Karen Coyle" <kcoyle@kcoyle.net> 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
>> 
>>https://github.com/w3c/data-shapes/commit/fb1fa5c994e3cfa1d74f93c3b5035c8
>>43a763ab4
>>
>> On Sat, May 14, 2016 at 8:24 AM, RDF Data Shapes Working Group Issue
>> Tracker <sysbot+tracker@w3.org <mailto:sysbot+tracker@w3.org>> wrote:
>>
>>     shapes-ISSUE-161 (terminology): [EDITORIAL] terminology fixups
>>     [SHACL Spec]
>>
>>     http://www.w3.org/2014/data-shapes/track/issues/161
>>
>>     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.
>>SHACL
>>     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: 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 Sunday, 15 May 2016 23:54:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:33 UTC