Re: ISSUE-78: Proposal for Abstract Classes Constraint

Holger, 

I see your point. But having a resource be both a shape and a class, 
although convenient in some situations, creates a tight coupling between 
the class and the shape. In the case of abstract classes, this tight 
coupling would seem useful as you suggest because the abstract constraint 
applies directly to the class and therefore all its instances.

But allowing the abstract constraint to be in a separate shape allows it 
to be applied to many classes, even perhaps different classes in different 
contexts. For example, if you used the state pattern to model different 
states of a resource as different subclasses, you might want to apply 
different abstract constraints to control which states the resource might 
be allowed to be in (which instances are allowed) in different lifecycle 
contexts.

It seems simple enough that we have the notion of Shape, and the notion of 
class scope. If we think of abstract as a constraint, then it seems 
reasonable to specify that constraint in a shape, along with other 
constraints that might be defined, and then apply that constraint in some 
scope. Then this allows different uses of a graph to apply different 
shapes for different purposes.

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




From:   Holger Knublauch <holger@topquadrant.com>
To:     public-data-shapes-wg@w3.org
Date:   04/13/2016 01:06 AM
Subject:        Re: ISSUE-78: Proposal for Abstract Classes Constraint



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: 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. 

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