Re: ISSUE-78: Proposal for Abstract Classes Constraint

Karen,
Thanks for the review and comments. 

Regarding SHOULD/MUST, in the absence of any motivating discussion I just 
stuck with what was already  there. Regarding the notion of abstract in 
the context of open-world assumptions, SHOULD could be motivated to 
maximize flexibility, and to allow different constraint spaces on the same 
vocabulary/graphs to co-exist. That is, if one usage pattern required the 
abstract constraint to be an error while another didn't, this wouldn't 
limit the ability to have the triples and generate a warning.

But we should follow the same pattern as any other SHACL constraint. If 
they are all MUST, then this one should be a MUST too.

I agree the second sentence is redundant.


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




From:   Karen Coyle <kcoyle@kcoyle.net>
To:     public-data-shapes-wg@w3.org
Date:   04/11/2016 06:12 PM
Subject:        Re: ISSUE-78: Proposal for Abstract Classes Constraint



Jim, I assume that if a data set or graph being validated has an 
instantiation of an abstract class, then that would be considered an 
error. In that case, I think that "SHOULD not be instantiated" has to be 
"MUST not be instantiated" or there is nothing to base error checking on.

I'm also confused about this, which appears in both versions:

Every instance of
 > an abstract class /SHOULD/also have an rdf:type triple to a 
non-abstract
 > subclass of the abstract class.

Again this would need to be MUST, not SHOULD. But it also seems 
redundant with what has already been said, and I'm not sure it is 
necessary.

kc

On 4/11/16 11:02 AM, 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
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600