Re: ISSUE-23: A proposal to not mingle shapes and classes

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