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


Received on Tuesday, 12 May 2015 22:52:28 UTC