Re: ISSUE-23: A specific proposal

Hi Holger,
 I think a key aspect of SHACL that would be nice to highlight is how
shapes can *specialize* existing Classes/Shapes. Example 1 shows a simple
example where the ex:Issue is declared as an rdfs:Class, but is
simultaneously specialized as a  Shape due to its associated SHACL
constraint. Can we, for the sake of simplicity and modularity, show how a
shape can be applied to an existing class? We could then demonstrate the
modularity by showing that we could have two shapes that specialize the
class.  How is exactly would that be done?

 I also wonder why sh:valueType doesn't just point directly to one value -
in this case a shape description that specializes schema:Person - e.g.
ex:SubmitterShape. That would eliminate sh:shape, a seemingly redundant
predicate to specify the value type.

Taking this approach would help users see a simpler, modular design. It
also actually follows what we already do with our SADI semantic web
services (where service inputs are specializations of ontology-defined
classes, and outputs are specializations of service inputs).

m.

Michel Dumontier, PhD
Associate Professor of Medicine (Biomedical Informatics)
Stanford University
http://dumontierlab.com

On Thu, Apr 23, 2015 at 4:18 PM, Holger Knublauch <holger@topquadrant.com>
wrote:

> In an attempt to make the discussion about ISSUE-23 [1] a bit more
> specific, I would like to suggest the following design. I have experimented
> with this design for a while and it appears to work nicely - both from an
> implementation perspective and user experience. My current draft [2] uses
> this design in its examples.
>
> In this proposal, the base class is sh:Shape, which carries the system
> properties to define constraints, i.e. sh:constraint, sh:property and
> sh:inverseProperty. sh:Shape can be instantiated and used by itself. To
> instruct a SHACL engine, the property sh:nodeShape is used to link a
> resource with its sh:Shape(s) that it is supposed to have. This design
> pattern is especially suitable for people who want to avoid any conflicts
> between existing RDFS data models and constraint checking.
>
> In the context of SHACL, rdfs:Class is declared as a rdfs:subClassOf
> sh:Shape, which means that any class can play the role of a Shape, and a
> Class can have constraints attached to it. Furthermore the rdf:type
> property is used by the SHACL engine to link instances with their class
> shapes, in the same way that sh:nodeShape is used. As a consequence, we
> have a natural implementation of specialization - rdfs:subClassOf is used
> to express sub-shape relationships.  This design pattern is especially
> suitable for people who want to naturally build upon the data models that
> already exist, and existing rdf:type triples.
>
> I believe this design produces a very attractive user-facing syntax (no
> bloating extra triples) while maintaining a very good level of flexibility
> and backwards compatibility. Existing RDFS/OWL ontologies and their
> instances can be incrementally enhanced with SHACL constraints.
>
> I would welcome specific, practice-oriented criticism of this design.
>
> Thanks,
> Holger
>
> [1] http://www.w3.org/2014/data-shapes/track/issues/23
> [2] http://w3c.github.io/data-shapes/shacl/
>
>
>