Re: ISSUE-23: sh:ShapeClass?

While I do not agree with the view point that classes and shapes are 
very different, I am certainly willing to work on a compromise that we 
can all live with, so that we can finally achieve a breakthrough on this 
pesky topic. Some people here suggest that SHACL should include a 
mechanism to establish links between classes and shapes, e.g.

     ex:MyClass
         a rdfs:Class .

     ex:MyShape
         a sh:Shape ;
         sh:classScope ex:MyClass ;
         sh:property [ ... ] .

or (inverse direction)

     ex:MyClass
         a rdfs:Class ;
         sh:classShape ex:MyShape .

     ex:MyShape
         a sh:Shape ;
         sh:property [ ... ] .

Linkage properties like sh:classScope and sh:classShape would support 
soft-coupling between classes and shapes for those who want to follow 
that design pattern.

However, the following would also be valid:

     ex:MyClassAndShape
         a rdfs:Class ;
         a sh:Shape ;
         sh:classShape ex:MyClassAndShape ;
         sh:property [ ... ] .

i.e. reuse the URI of the class also for its shape and use sh:classShape 
to point back to itself.

I believe I could live with sh:classShape or sh:classScope, if we also 
introduced syntactic sugar for the case above. We should introduce a 
metaclass

     sh:ShapeClass
         a rdfs:Class ;
         rdfs:subClassOf sh:Shape ;
         rdfs:subClassOf rdfs:Class .

which would be instantiated as follows:

     ex:MyClassAndShape
         a sh:ShapeClass ;
         sh:property [ ... ] .

Such ShapeClasses would be instances of sh:Shape and rdfs:Class at the 
same time. In order to avoid the need to write down the superfluous 
sh:classShape triple pointing to itself, the engine would assume that 
this triple exists - a fairly small change to the algorithm. Introducing 
sh:ShapeClass would be similar to having owl:Class, which extends the 
rdfs:Class metaclass with additional properties. By having users 
instantiate the new metaclass they make a conscious choice that the URI 
of that class can also be used as a shape. The benefit is that we still 
have readable code with much fewer triples, and fewer people facepalming 
about the complexity of the trivial use cases - why introduce a separate 
sh:Shape when there is a one-to-one mapping anyway.

Thanks for your feedback,
Holger


On 4/29/2015 23:31, Michel Dumontier wrote:
> In case it wasn't clear, i meant that I don't support direct 
> annotation of a class. the target of a shape should be referenced by 
> the shape.
>
> m
>
>
>
> On Apr 29, 2015, at 1:42 AM, Dimitris Kontokostas <jimkont@gmail.com 
> <mailto:jimkont@gmail.com>> wrote:
>
>> I also support this approach as a direct association of a shape to a 
>> class. Indirection comes when we try to guess it from other triples 
>> associated with the shape resource.
>>
>> Best,
>> Dimitris
>>
>> On Apr 29, 2015 03:33, "Michel Dumontier" 
>> <michel.dumontier@stanford.edu 
>> <mailto:michel.dumontier@stanford.edu>> wrote:
>>
>>     I support this proposal. I believe it is important that shapes
>>     and classes be considered different, and that it is user-defined
>>     shapes that may refer to class expressions or other shapes.
>>
>>     m.
>>
>>     Michel Dumontier, PhD
>>     Associate Professor of Medicine (Biomedical Informatics)
>>     Stanford University
>>     http://dumontierlab.com
>>
>>     On Tue, Apr 28, 2015 at 6:20 PM, Holger Knublauch
>>     <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>>
>>         Your sh:classScope looks exactly like the sh:classShape used
>>         in my previous email, only in the inverse direction. I don't
>>         see how this avoids mingling between classes and shapes - it
>>         just adds a level of indirection. Selection still happens by
>>         rdf:types and rdfs:subClassOf inheritance still remains
>>         meaningful. It's just another syntax for the same concepts.
>>
>>         Holger
>>
>>
>>
>>         On 4/29/2015 10:51, Peter F. Patel-Schneider wrote:
>>
>>             -----BEGIN PGP SIGNED MESSAGE-----
>>             Hash: SHA256
>>
>>             I propose that there be no mingling of RDFS classes and
>>             shapes, constraints,
>>             or anything else in the SHACL specification. This
>>             proposal, I believe, is
>>             consonant with Stardog ICV, with Shape Expressions, and
>>             with Resource
>>             Shapes.  Selection of which nodes to verify would be done
>>             using mechanisms
>>             different from those used in RDFS, although some
>>             selection would interact
>>             with RDFS classes and properties.  One specific set of
>>             mechanisms that work
>>             this way can be found in
>>             https://www.w3.org/2014/data-shapes/wiki/Shacl-sparql
>>             where there are
>>             several kinds of scoping links that say which nodes are
>>             to be checked
>>             against a shape.
>>
>>             One of these kinds of scoping links links to a class, and
>>             requires all
>>             instances of the class be checked against a shape.  So
>>             for checking that all
>>             people's parents are people one could* say:
>>
>>             [ sh:classScope ex:Person ;
>>                sh:shape [ sh:predicate ex:parent ;
>>                           sh:valueType ex:Person ] ]
>>
>>             peter
>>
>>
>>
>>             * This is written in the representationally relaxed variant.
>>             -----BEGIN PGP SIGNATURE-----
>>             Version: GnuPG v2
>>
>>             iQEcBAEBCAAGBQJVQCr9AAoJECjN6+QThfjz3vcIANEl+Zjrp6eOri6cA66e5Yk5
>>             gvI/N3/1bf4UxNJyLmHPp8diqHKo97ZcRD4lZw/Haf6hsGoTEpThlNBKaCXTwpv0
>>             QZJzJHcyR+9thYmSbFElUVVu9cWH2sHakHANCbyXzmVbuemfGDfVdu3ud3V/QlP1
>>             Br5k+PSIPRImVWXGszC9/32HmP/l41Wu6nEcExsz3FjrR1xAhGHeavdONifjhBaU
>>             pLBnp4AkNkkHzhmXPLKevgokmx3vZ/WztTfc2YUhZNvueY4utaM4RTKzGkmT8uSe
>>             CzK6p1Svr9jeJ6ecEqqCxw3NvhYlkZ94+iI4wQtxMIGhkKmyjSJlQk2yoVokBVM=
>>             =txRC
>>             -----END PGP SIGNATURE-----
>>
>>
>>
>>