Re: ISSUE-23: sh:ShapeClass?

On Mon, May 11, 2015 at 2:50 AM, Holger Knublauch <holger@topquadrant.com>
wrote:

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

Up to this point, my proposal was identical to yours but only excluding the
sh:ShapeClass rdfs:subClassOf rdfs:Class statement.
This means that if someone wants to define a shape and a class in the same
graph he would have to specify both types while in your design only
sh:ShapeClass would be enough

While I am not aware of any problems in semantics this could introduce,
from the top of my head it would break many existing user tools that try to
get simple ontology information since it would hide the rdfs:Class
statement from the classes.
Also how would your approach interact with owl:Thing, subclasses of
owl:Thing or other subclasses of rdfs:Class?

If this doesn't work out in the end, users who prefer to avoid the extra
typing of both "a rdfs:Class, sh:ShapeClass" could define the relation
manually in their ontology / shape graph.


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

I don't have a *very* strong opinion on these but I think a SHACL engine
(as well as the users who read shape definitions) should be able to
immediately see how a shape is defined and how it will be applied on the
data graph. With the introduction of sh:ShapeClass things got a little bit
more clear but there is still room for improvement.
A rational for this is again SPARQL endpoints. In this case we want to be
able to pre-generate as much information as possible to avoid the
communication between the SHACL engine and the shapes / data graph.
With this approach we could also set the range of sh:nodeShape to
sh:ResourceShape and allow ClassShapes to be linked with sh:valueType

Best,
Dimtiris


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


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