- From: Holger Knublauch <holger@topquadrant.com>
- Date: Fri, 30 Oct 2015 16:28:35 +1000
- To: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
Arthur, On 10/29/2015 22:23, Arthur Ryman wrote: > Holger, > > 1. Yes, I agree that we need a concrete alternative for the SHACL data > model. We should start with a minimal Turtle vocabulary file which > contains all the terms we use in the spec and only add features agreed > to by the WG. I have made another pass through "my" Turtle file, currently at https://github.com/TopQuadrant/shacl/blob/master/src/main/resources/etc/shacl.ttl I have cleaned up a few things, deleted unapproved features and added TODO comments with links to open ISSUEs for features at risk. I believe this incremental approach is more helpful than reinventing the wheel with a blank sheet of paper. Here is an outline of what it is currently in the file: 1) Shape Classes (sh:Shape, sh:ShapeClass) 2) Shapes that extend existing RDFS/OWL to declare sh:entailment, sh:shapesGraph 3) Node Kind vocabulary (sh:BlankNode, sh:IRI etc) 4) Results vocabulary (sh:ValidationResult etc) 5) Macros meta-model (sh:Function, sh:Template etc) 6) The sh:sparql property 7) Scope vocabulary (sh:PropertyScope etc) 8) Constraint vocabulary (sh:Constraint, templates etc) All this is quite generic and would need to be part of any proper SHACL model. 9) The specific constraint types (sh:PropertyConstraint, sh:NodeConstraint etc) 10) The specific functions used by the constraint types These two parts are about 60% of the document. This will become significantly shorter if I am allowed to proceed with my proposal to ISSUE-95. Yet, they do define all the details about the allowed constraint properties that is needed in one way or another, so we cannot completely drop them. A contentious issue may be that my current file includes the SPARQL queries. I may be able to live with taking those out of the published vocabulary. Yet, I would then still need stable URIs to attach the SPARQL queries that I want to use to, and this is what the abstract template classes and functions provide. 11) Declarations of defaultValueTypes 12) Definition of some RDFS system classes so that constraint checking of shapes graphs can pass 13) Declarations of rdf:Properties for the built-ins, with a label, for legacy applications Some of that content could be taken out of the file too. > > 2. I believe the WG should give first precedence to making SHACL easy > to understand for people who are going to write SHACL documents. We > should not sacrifice that for technical advantages related to > validating SHACL documents. Since we can generate RDFS, OWL or HTML versions from a SHACL model, I don't see any of this blocking the other. However, I do believe that we shouldn't let the current status of SHACL cloud our judgement about how the language should be layered in general. In particular, statements such as "nobody understands SHACL yet so we should not rely on it yet" would be short-sighted. In a year from now, there will be lots of articles, tutorials, tools and probably even books written about SHACL. In two years from now, people would wonder why the hell did the WG not use SHACL to describe the SHACL vocabulary itself. Only because some people didn't grasp the details of the metaclasses at this stage, yet, and because the spec that is supposed to explain these things is unfinished and poorly written? How many people here in the WG have actually used SHACL yet? We are all beginners right now, but that will change quickly. Holger > > 3. My second line of reasoning relates to the use of meta-classes. I > believe it is very easy to get lost when mentally traversing > meta-levels. I believe data models are easier to understand when > meta-classes are avoided. I believe the OWL approach of classifying > all terms as classes, properties, or individuals results in data > models that are easier to understand. Yes, avoiding meta-classes is a > matter of personal taste but it makes data models clearer. > > -- Arthur >
Received on Friday, 30 October 2015 06:30:21 UTC