Re: ISSUE-23: sh:ShapeClass?

On 5/12/2015 18:56, Dimitris Kontokostas wrote:
>
> 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.

Nobody would be forced to use sh:ShapeClass. Many people will prefer to 
simply add rdf:type sh:Shape to their existing classes, including OWL 
and RDFS classes. Some may decide to put these triples into another file 
to keep these worlds separated - some OWL DL applications may be unhappy 
about the SHACL triples anyway. OWL Full and general RDFS applications 
shouldn't have problems with new metaclasses - owl:Class being a 
subclass of rdfs:Class is already such an example, and sh:ShapeClass 
follows the same design principle. Therefore, as you also state below, 
people can simply add the required triples to declare that sh:ShapeClass 
rdfs:subClassOf rdfs:Class. One way of doing this would be to add an 
owl:imports statement into the SHACL system namespace. Maybe we should 
produce a small OWL-friendly system namespace that would declare things 
like sh:property rdfs:domain sh:Shape. OWL/RDFS inference engines could 
then infer the missing triples to understand that sh:ShapeClass must be 
a metaclass.

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

(BTW I have recently simplified my draft by removing global constraints 
altogether - the same effect can be achieved by attaching a shape to the 
Graph object via sh:nodeShape, as outlined in 
http://w3c.github.io/data-shapes/shacl/#graph-constraints . The design 
is much more consistent now.)

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

sh:valueType is supposed to check for rdf:type triples only, which must 
be classes, not shapes. Of course if the class is also a shape (e.g. 
sh:ShapeClass) then people can already use sh:valueType.

I am probably not understanding your proposal in detail, but I see no 
difference between a hypothetical class sh:ResourceShape and 
sh:ClassShape - they all seem to refer to a focus node. Given that many 
people will want to reuse a shape either with sh:nodeShape or 
sh:scopeClass I believe it would unnecessarily constrain reuse 
opportunities. You mention potential issues with SPARQL end points, and 
this is indeed important. But I believe we need specific examples to 
have a more focused and informed discussion about the problems that may 
arise. Static analysis of the SPARQL queries may help, e.g. to determine 
whether they use ?shapesGraph and thus require round-trips back to the 
shapes server. For the SPARQL end point scenario, this info may be more 
relevant than the type of the shapes class.

Thanks
Holger