Re: ISSUE-23: sh:ShapeClass?

Unless we declare rdfs:Class to be disjoint with sh:Shape we cannot enforce
users not to use the same IRI for both.
I am skeptical to direct relations from sh:Shape(s) to rdfs:Class (e.g.
rdfs:subClassOf) but, if we drop these for now until we make sure they do
not cause any problems it would be fine for me to start with something like

#1 separate definition
ex:ClassA a rdfs:Class .
ex:ShapeA a sh:ClassShape ;
     sh:class ex:ClassA .

#2 use of the same IRI if sh:class does not exists
ex:ClassA a rdfs:Class, sh:ClassShape .

note that in option 2 we still have to declare ex:ClassA to be a
sh:ClassShape in addition to rdfs:Class.
My top-level class definition would be something like the following without
interfering with rdfs/owl reasoning

sh:Shape a rdfs:Class. # "abstract" class not directly instantiated
sh:ClassShape a rdfs:Class ; rdfs:subClassOf sh:Shape . #Shapes used for
classes
sh:ResourceShape a rdfs:Class ; rdfs:subClassOf sh:Shape . #Shapes used for
ShEx shapes
sh:GlobalShape a rdfs:Class ; rdfs:subClassOf sh:Shape . #Shapes used for
global constraints
# additional shape types we might introduce e.g. sh:PropertyShape

Could something like this set a common-ground to start with?

Best,
Dimitris


On Thu, May 7, 2015 at 2:33 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

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


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