Re: ISSUE-23: A specific proposal

On 4/24/15 10:15 AM, Michel Dumontier wrote:
> 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?
In my current proposal, if a shape is supposed to participate in a 
specialization relationship, then it should be declared as an 
rdfs:Class. There is no real downside from a Shape perspective - it is 
still a shape even if it is (also) a class. Having two parallel 
specializations hierarchies would IMHO lead to chaos and unnecessary 
overhead.

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

sh:valueType restricts the rdf:type triple that is stored in the model. 
sh:shape only defines additional constraints that these values also need 
to have (possibly in addition to being an instance of schema:Person). 
sh:shape actually walks into the nested properties of the given shape, 
while sh:valueType only scratches the surface and only looks for the 
rdf:type triple. Since these are very different use cases, I believe we 
still need both.

Holger

>
> 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 <mailto: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/
>
>
>