W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > April 2016

Re: ISSUE-78: Proposal for Abstract Classes Constraint

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:31 UTC