Re: ISSUE-23: sh:ShapeClass?

Back in February, after long discussions, we made a formal resolution 
[1] to "explore ways to combine shapes and classes such as punning". In 
the last call, Peter stated something along the lines of "this may lead 
to problems that are better left unexplored", contradicting our resolution.

In the absence of strong evidence for specific problems, we should 
assume that some form of reusing class IRIs as shapes will be 
acceptable. If we discover serious problems then we could document these 
problems and the situations in which they may occur.

Yet this remains a topic that we need to address and take seriously. 
Almost all currently existing RDF/OWL data is class-centric, and we need 
to have a user-friendly story to extend these data models. Forcing users 
to duplicate all their classes with shapes, dictating a certain design 
patterns upon everyone, is IMHO a non-starter. With SPIN we have mixed 
constraints and classes for many years and never ran into problems.

More comments to Dimitris' specific suggestion below.

[1] http://www.w3.org/2015/02/18-shapes-minutes.html#resolution01

On 5/8/2015 17:45, Dimitris Kontokostas wrote:
> 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

I would like to hear what problems have been identified before 
pre-emptively assuming that problems exist. Did you find specific 
problems with my proposed design, see class diagram at 
http://w3c.github.io/data-shapes/shacl/#shape-classes ?

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

In my proposal, people can do this too, e.g.

ex:ClassA a rdfs:Class  # Possibly stored in the "ontology" file
ex:ClassA a sh:Shape  # Possibly stored in the "shapes" file

> 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

I don't see why we should introduce new classes to distinguish "class" 
and "resource" shapes. This is already expressed via the relationships, 
e.g. sh:nodeShape and sh:scopeClass (your sh:class above).

> sh:GlobalShape a rdfs:Class ; rdfs:subClassOf sh:Shape . #Shapes used 
> for global constraints

Global shapes do not exist in my design - they are just global 
*constraints*. A shape is assumed to have a focus node, and what would 
be the focus node of a "global" shape? A design pattern may emerge that 
people attach graph-level conditions to the graph resource itself 
(owl:Ontology etc) so maybe we don't even need global constraints in the 
final design, simplifying the metamodel.

Thanks,
Holger


> # 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 <mailto: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
>