Re: ISSUE-78: Proposal for Abstract Classes Constraint

Jim, if you agree we could rephrase your proposal as follows:

sh:abstract is a sh:NodeConstraint that requires a node to have only
triples with the rdf:type predicate

some scopes other than class scopes might not make sense or result in
invalid shapes but we should not tight the constraint with a specific scope.

Dimitris

On Thu, Apr 14, 2016 at 4:41 PM, Jim Amsden <jamsden@us.ibm.com> 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
>
>
>
>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects: http://dbpedia.org, http://rdfunit.aksw.org, http://
http://aligned-project.eu
Homepage:http://aksw.org/DimitrisKontokostas
Research Group: AKSW/KILT http://aksw.org/Groups/KILT