- From: Holger Knublauch <holger@topquadrant.com>
- Date: Fri, 23 Oct 2015 05:48:39 +1000
- To: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
If this explanation is too long, then sh:scopeClass in general is too complex. All I did is to apply our own technology consistently, just like the OWL people did with owl:Restrictions. As I explained, this consistency provides numerous benefits which a newly minted property would drop. I also strongly disagree with the repeated claims that "this just reflects Holger's specific implementation". This is completely untrue. In fact the whole topic is part of the extension mechanism, which is part of SHACL. The details of this have no impact on the Core Language, if this is what you are concerned about. Holger On 10/23/15 4:25 AM, Arthur Ryman wrote: > Holger, > > Your explanation is too long for our target users to understand. It > would be clearer if we defined a new term for this purpose instead of > reusing sh:scopeClass. > > -- Arthur > > On Thu, Oct 15, 2015 at 8:36 PM, Holger Knublauch > <holger@topquadrant.com> wrote: >> Hi Arthur, >> >> I know the rationale behind this design isn't entirely obvious. This is in >> part because the design is liberally moving between various metalevels, and >> templates are also shapes in my design. But there is a precedent for this: >> >> OWL has owl:Restrictions, which are defined using rdfs:subClassOf, e.g. >> >> ex:Person >> a owl:Class ; >> rdfs:subClassOf ex:Animal ; >> rdfs:subClassOf [ >> a owl:Restriction ; >> owl:onProperty ex:firstName ; >> owl:allValuesFrom xsd:string ; >> ] . >> >> Arguably, the designers could have created a new property owl:restrictedBy >> to distinguish restrictions from named superclasses, but since there is no >> logical difference between restrictions and other classes, they chose to >> reuse the same subset mechanism. However, seeing restrictions defined as >> superclasses also sometimes confuses people and tools may want to handle >> them different too. Yet, the overall language design is consistent, and does >> make sense if you dive deep enough. >> >> In the case of SHACL, let my try to walk through this step by step. >> >> 1) sh:Arguments are constraints. >> >> For example, if you define >> >> ex:MyTemplate >> a sh:ConstraintTemplate ; >> sh:argument [ >> sh:predicate ex:myProperty . >> sh:datatype xsd:integer . >> ] . >> >> and then you instantiate >> >> ex:MyShape >> sh:constraint [ >> a ex:MyTemplate ; >> ex:myProperty 4.2 ; >> ] . >> >> this would be flagged as a violation, because ex:myProperty must have >> xsd:integers, not xsd:decimals. >> >> >> 2) sh:scopeClass is a bit like superClassOf >> >> From a validation point of view, there is no difference between: >> >> a) ex:MySubTemplate rdfs:subClassOf ex:MyTemplate . >> >> b) ex:MyTemplate sh:scopeClass ex:MySubTemplate . >> >> If you have an instance of ex:MySubTemplate, then all constraints attached >> to ex:MyTemplate also apply, e.g. if ex:MyTemplate is the scopeClass of some >> shape, or if ex:MyTemplate is a ShapeClass itself (which it is in my >> design). This is the same situation with an inferencing-based approach, >> where the constraints at MyTemplate also "inherit" down into MySubTemplate >> (let's please not fight over terminology here). >> >> >> 3) Constraints define the structure of data >> >> Constraints such as sh:property and sh:argument declare "applicable" >> properties. Tools can use this information to build up input forms etc. >> Attached is an input form from TopBraid, which shows that we were able to >> use the very same mechanisms to build a form either for a shape or its >> property constraints. It is a very common scenario to have algorithms that >> walk through all applicable properties and do something. All we need to do >> here is to follow rdfs:subClassOf and sh:scopeClass links. It would be a >> wasted opportunity to require yet another mechanism to find the applicable >> properties, especially if this mechanism only applies to certain kinds of >> objects (here: template definitions). This doesn't only impact the >> compactness of the algorithms and SPARQL queries, but also their performance >> - one more property to check at every step. >> >> The same argument applies to validation: with the consistent mechanism >> people can run SHACL engines over SHACL files, e.g. to check the syntax of >> their constraint definitions. >> >> The redesign fixes a previous issue with the spec, which was reusing >> rdfs:subClassOf to mean two different things (argument inheritance versus >> template injection). The redesign intentionally fixes this without >> introducing any new custom properties. >> >> Does this make more sense now? I do believe this issue will only ever have >> to be fully understood by few people - only a subset of SHACL users will >> write their own templates, and from those almost everyone will either use a >> wizard-like tool or copy-and-paste from another example template in >> Tutorials. Whether they see sh:scopeClass or sh:injectedInto in their copied >> snippets will not make any difference to them. However, sh:injectedInto >> would be extra work for all algorithms that try to make sense of a SHACL >> document. >> >> Thanks >> Holger >> >> >> >> >> >> On 10/16/2015 4:09, Arthur Ryman wrote: >>> I looked at Holger's proposal. It looks like sh:scopeClass is being >>> used for a completely different purpose than its original purpose >>> which was to define the scope of a shape as being a class. In Holger's >>> proposal it is being used to inject a node constraint into a property >>> constraint. >>> >>> I'd like to see a new predicate used for template injection. >>> >>> -- Arthur >>>
Received on Thursday, 22 October 2015 19:49:13 UTC