Re: ISSUE-23: sh:ShapeClass?

I have meanwhile updated my draft to include sh:ShapeClass. Works 
nicely. I added an illustration that may help understand how these 
metaclasses relate to each other:

     http://w3c.github.io/data-shapes/shacl/#shape-classes

As shown in the illustration, I have added a relationship sh:scopeClass 
that points from a sh:Shape to an rdfs:Class. This should cover the 
cases where classes and shapes are developed and maintained 
independently. To clarify its role, I have renamed the property formerly 
known as sh:scope to sh:scopeShape. I also updated my prototype 
implementation and noticed that sh:scopeClass introduces all kinds of 
complications that will need to be worked out, e.g. the sh:scopeClass 
triples will live in the Shapes graphs, while the rdf:type triples 
remain in the data graphs.

On this occasion I also created a diagram for some of the constraint types:

     http://w3c.github.io/data-shapes/shacl/#shape-constraints

Feedback appreciated, as usual.

Holger


On 4/30/2015 12:34, Holger Knublauch wrote:
> 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