Fwd: Re: ISSUE-23: sh:ShapeClass?

On 05/13/2015 01:50 AM, Holger Knublauch wrote:
> 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.

If the metaclass is used only for the people who prefer to avoid the 
typing of an extra type statement I would prefer they do it in their own 
namespace. I would rather make sh:ShapeClass a subClass of sh:Shape only 
but this is only my opinion,

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

You are right I am not very clear I made an issue on this to see where 
the WG stands in order to provide more details. Scope is not taken into 
account in your definition of the sh:hasShape SPARQL function see 
issue-49. Also recursion and (maybe) closed shapes will also greatly 
affect the round trips. If we do not allow them at all things will be 
very simple which ever way we choose.

Best,
Dimitris

>
> Thanks
> Holger
>