Re: ISSUE-23: A specific proposal

On 4/28/15 12:13 AM, Dimitris Kontokostas wrote:
>
>
> On Fri, Apr 24, 2015 at 1:18 AM, 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. 
>
>
> If we use rdfs:subClassOf to express sub-shape relationships how can 
> we distinguish between class shapes and ShEx shapes?

I assume you mean stand-alone shapes (instances of sh:Shape) when you 
refer to ShEx shapes? You can use rdfs:subClassOf in any case. 
rdfs:Class is in this design a subclass of sh:Shape, so you could either 
use rdfs:Class instead of sh:Shape (when you want to make them 
sub-shapes), or simply use rdfs:subClassOf between Shapes (in which case 
an RDFS inference engine would infer the rdf:type. Given all trade-offs, 
I don't see a much better viable alternative to this design. What 
concerns do you have specifically? Could you give an example?

Holger


>     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/
>
>
>
>
>
> -- 
> Dimitris Kontokostas
> Department of Computer Science, University of Leipzig & DBpedia 
> Association
> Projects: http://dbpedia.org, http://http://aligned-project.eu
> Homepage:http://aksw.org/DimitrisKontokostas
> Research Group: http://aksw.org
>