Re: ISSUE-78: Proposal for Abstract Classes Constraint

On 30/04/2016 4:52, Jim Amsden wrote:
> 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.

I think it's important to clarify that reusing the same URI for classes 
and shapes does not stop anyone from reusing a class in a different 
context. The duality of sh:Shape and rdfs:Class only must exist in the 
shapes graph, i.e. it is perfectly valid to have a data graph that 
defines ex:MyClass as a class only, while the shapes graph *adds* the 
sh:Shape triple. Whether you use the same URI or mint a new URI such as 
ex:MyClassShape makes no difference. The data graph can still be reused 
elsewhere, with another shape.

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

Yes, but then why not sh:scopeNode and other scopes, or the implicit 
sh:scopeClass triple of shapes that are also classes? This makes the 
whole approach rather inconsistent with the rest of the scoping mechanism.

Such a condition is also quite hard to formalize with our current 
mechanisms (in SPARQL). Do you have a SPARQL definition that would work 
for you? I tried, but gave up. It would require knowledge about the 
current scope that we are looking at at evaluation time of the WHERE clause.

Holger


>
>
> 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>_ 
> <mailto:holger@topquadrant.com>
> To: _public-data-shapes-wg@w3.org_ <mailto: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
>
>
>
>
>
>
>