Re: ISSUE-78: Proposal for Abstract Classes Constraint

Holger,
It's very possible that I don't fully understand the issues you are 
raising. However it seems my proposal and yours have the identical effect. 


Your example:

ex:MyClass
    a rdfs:Class, sh:Shape ;
    sh:constraint sh:Abstract .

which implies the following node constraint:

sh:Abstract
    a sh:NodeConstraint ;
    sh:abstract true .

simply says ex:MyClass is abstract. In your approach, ex:MyClass has to 
also be an sh:Shape in order to apply the sh:constraint property.

But this seems unnecessary. In my approach, ex:MyClass is just an RDF 
class.

ex:MyClass
    a rdfs:Class ;
    dcterms:title: "MyClass" .

The class, like most classes, is described without including any 
constraints in order for the same class to be constrained for different 
purposes in different usage scenarios, in different graphs.

The constraint is applied by using a scope class to define the constraint 
and reference the constrained class:

sh:Abstract
    a sh:NodeConstraint ;
    sh:scopeClass ex:MyClass ;
    sh:abstract true .

When the graph containing this shape is applied to the graph containing 
ex:MyClass, the constraint takes effect and restricts the creation of 
direct instances of ex:MyClass. Other graphs might use ex:MyClass in 
situations where it could have direct instances in which case perhaps 
different or no constraints are applied.

Regarding you questions:

- how to find the current class we are looking at and its subclasses only 
- as specified by the sh:scopeClass values of the constraint.
- how to establish the linkage between class and shape (sh:scopeClass 
only, why?) - using sh:scopeClass, seems sufficient.


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" <public-data-shapes-wg@w3.org>
Date:   04/14/2016 03:44 PM
Subject:        Re: ISSUE-78: Proposal for Abstract Classes Constraint



I believe you'd need to formulate a very precise definition of how this 
should be defined. I tried it, but failed, because of issues such as
- how to find the current class we are looking at and its subclasses only
- how to establish the linkage between class and shape (sh:scopeClass 
only, why?)

If someone can come up with a suitable defintion, then I'll throw my 
support back into the ring.

My preferred alternative would have been to just make this a boolean 
annotation property on rdfs:Class. We have other non-validating properties 
elsewhere. Such an annotation property is enough to guide UI tools. But 
people will argue that such a boolean doesn't belong into SHACL. The 
counter argument would be that even our own data model uses abstract 
classes (sh:Constraint for example), so putting some formal grounding 
would make sense.

Holger


On 14/04/2016 23:41, Jim Amsden wrote:
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