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_ 
> <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
>
>
>
>