- From: Holger Knublauch <holger@topquadrant.com>
- Date: Wed, 13 Apr 2016 15:05:03 +1000
- To: public-data-shapes-wg@w3.org
- Message-ID: <570DD37F.8060508@topquadrant.com>
Hi Jim, I've thought a lot a bit this feature recently, but came to the conclusion that it only made sense for classes that are also shapes. Going the extra step via sh:scopeClass feels artificial and makes the whole thing rather hard to justify, because abstractness is really not a property of a shape. We have taken sh:ShapeClass out of the spec, so the only case that I would find reasonable would be: ex:MyClass a rdfs:Class, sh:Shape ; sh:constraint sh:Abstract . Above, sh:Abstract would be a syntactic sugar instance of sh:NodeConstraint that can be shared across classes: sh:Abstract a sh:NodeConstraint ; sh:abstract true . The condition would then be that all instances of ex:MyClass must also have at least one rdf:type triple for a subclass of ex:MyClass, where NOT EXISTS { ?subClass sh:constraint/sh:abstract true } in the $shapesGraph. Can you tell whether such mixed class/shapes are an option? Holger On 12/04/2016 4:02, Jim Amsden wrote: > re: ISSUE-78: Abstract Classes > <https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-78:_Abstract_Classeshttps://www.w3.org/2014/data-shapes/wiki/Proposals>: > There is no use case or requirement for SHACL to support abstract > classes, but _the issue_ > <https://www.w3.org/2014/data-shapes/track/issues/78>provides > reasonable motivation and the votes on the issue are >0. > > The current spec contains the following paragraph in section 2.1.2.1 > Implicit Class Scopes: > > Classes may be declared to be abstract by setting their property > sh:abstract to true. Abstract classes /SHOULD/not be instantiated > directly, i.e. every instance of an abstract class /SHOULD/ also have > an rdf:type triple to a non-abstract subclass of the abstract class. > > where "Classes" references sh:ShapeClass. The concept of abstract > class could instead be expressed as a node constraint. This would > allow a class to be abstract or concrete in different situations based > on the domain needs. > > Proposal: > > Remove the paragraph about abstract classes from section 2.1.2.1. > > Add sh:abstract to the table in section 3 and indicate that it is a > sh:NodeConstraint. > > Add section 3.10 Abstract Class Constraint > > Classes may be constrained to be abstract by creating a node > constraint with class scope, and including the sh:isAbstract property > set to true. Abstract classes /SHOULD/not be instantiated directly. > Every instance of an abstract class /SHOULD/also have an rdf:type > triple to a non-abstract subclass of the abstract class. > > #Example abstract class constraint: > > ex:AnAbstractClassConstraint > a sh:Shape ; > sh:scopeNode ex:AnAbstractClass ; > sh:isAbstract true . > > #Example graph data > > ex:AnAbstractClass > a rdfs:Class ; > dcterms:title "Example of an abstract class constraint." . > > Jim Amsden, Senior Technical Staff Member > OSLC and Linked Lifecycle Data > 919-525-6575 >
Received on Wednesday, 13 April 2016 05:05:39 UTC