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

Re: shapes-ISSUE-161 (terminology): [EDITORIAL] terminology fixups [SHACL Spec]

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Sun, 15 May 2016 10:53:34 -0700
To: public-data-shapes-wg@w3.org
Message-ID: <5738B79E.6050209@kcoyle.net>
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/fb1fa5c994e3cfa1d74f93c3b5035c843a763ab4
>
> 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 17:54:00 UTC

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