- 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