Re: ISSUE-78: Proposal for Abstract Classes Constraint

Eric,
Re: Most of SHACL doesn't depend on your triple's. Perhaps it would be 
more practical to say that validating a focus node as abstract class 
succeeds if the node matches exactly one leaf shape. A leaf shape is any 
shape C which is derived from another shape A where there is no shape 
derived from C.

The concept of abstract class is being applied as a node constraint to an 
in-scope focus class, not the shapes. So the concept of derived shapes 
doesn't apply - but perhaps that would be a different use case. 

Regarding validation, the constraint would be satisfied if any instance of 
an abstract class was also an instance of a concrete subclass of that 
class - it doesn't need to be a leaf-class, just a concrete subclass.

 

Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575




From:   "Eric Prud'hommeaux" <eric@w3.org>
To:     Jim Amsden/Raleigh/IBM@IBMUS
Cc:     public-data-shapes-wg <public-data-shapes-wg@w3.org>
Date:   04/12/2016 04:44 AM
Subject:        Re: ISSUE-78: Proposal for Abstract Classes Constraint
Sent by:        ericw3c@gmail.com




On Apr 11, 2016 2:03 PM, "Jim Amsden" <jamsden@us.ibm.com> wrote:
>
> re: ISSUE-78: Abstract Classes: There is no use case or requirement for 
SHACL to support abstract classes, but the issue 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 SHOULDnot 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. 
Most of SHACL doesn't depend on your triple's. Perhaps it would be more 
practical to say that validating a focus node as abstract class succeeds 
if the node matches exactly one leaf shape. A leaf shape is any shape C 
which is derived from another shape A where there is no shape derived from 
C.
+1 to Karen's MUST comments.
> 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 SHOULDnot be instantiated directly. Every instance of an 
abstract class SHOULDalso 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
>