- From: Holger Knublauch <holger@topquadrant.com>
- Date: Mon, 16 May 2016 10:53:22 +1000
- To: public-data-shapes-wg@w3.org
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: https://github.com/w3c/data-shapes/commit/3add4a80e92aa32e7e43634c371b79357a083f9f Thanks, Holger > > 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 Monday, 16 May 2016 00:53:58 UTC