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

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> 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