Re: ISSUE-78: Proposal for Abstract Classes Constraint

On Apr 12, 2016 10:03 AM, "Jim Amsden" <jamsden@us.ibm.com> wrote:
>
> Eric,
> Re: Most of SHACL doesn't depend on your triple's. Perhaps it would be
more

Sigh. Glide error. That was supposed to be "type triples". My point is that
I don't think we want to the the behavior of " abstract" to type arcs
attached to a nice but instead the shapes to which that node conforms.

> practical to say that validating a focus node as abstract class succeeds
if the node matches exactly one leaf shape. A leaf shape is any shape C
which is derived from another shape A where there is no shape derived from
C.
>
> The concept of abstract class is being applied as a node constraint to an
in-scope focus class, not the shapes. So the concept of derived shapes
doesn't apply - but perhaps that would be a different use case.
>
> Regarding validation, the constraint would be satisfied if any instance
of an abstract class was also an instance of a concrete subclass of that
class - it doesn't need to be a leaf-class, just a concrete subclass.
>
>
>
>
> Jim Amsden, Senior Technical Staff Member
> OSLC and Linked Lifecycle Data
> 919-525-6575
>
>
>
>
> From:        "Eric Prud'hommeaux" <eric@w3.org>
> To:        Jim Amsden/Raleigh/IBM@IBMUS
> Cc:        public-data-shapes-wg <public-data-shapes-wg@w3.org>
> Date:        04/12/2016 04:44 AM
>
> Subject:        Re: ISSUE-78: Proposal for Abstract Classes Constraint
> Sent by:        ericw3c@gmail.com
> ________________________________
>
>
>
>
> On Apr 11, 2016 2:03 PM, "Jim Amsden" <jamsden@us.ibm.com> wrote:
> >
> > re: ISSUE-78: Abstract Classes: There is no use case or requirement for
SHACL to support abstract classes, but the issue 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 SHOULDnot 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.
>
> Most of SHACL doesn't depend on your triple's. Perhaps it would be more
practical to say that validating a focus node as abstract class succeeds if
the node matches exactly one leaf shape. A leaf shape is any shape C which
is derived from another shape A where there is no shape derived from C.
>
> +1 to Karen's MUST comments.
>
> > 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 SHOULDnot be instantiated directly. Every instance of an
abstract class SHOULDalso 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
> >
>
>