Re: ISSUE-23: A specific proposal

Holger,
  You misunderstand, I do not want two parallel specialization hierarchies
- I want one. Consider this alternative formulation that uses
rdfs:subClassOf to invoke the class specialization:

ex:Issue
  a rdfs:Class;
  rdfs:label "An issue is a topic for discussion" .

ex:IssueShape
  rdfs:subClassOf ex:Issue;
  sh:property [
sh:predicate ex:assignedTo ;
rdfs:label "assigned to" ;
rdfs:comment "The assigned of an issue must be a person." ;
sh:maxCount 1 ;
sh:valueType schema:Person ;
  ] ;
  sh:property [
sh:predicate ex:submittedBy ;
rdfs:label "submitted by" ;
rdfs:comment "The submitter of an issue must be a person who also has an
email address." ;
sh:minCount 1 ;
sh:maxCount 1 ;
sh:valueType ex:SubmitterShape ;
  ] .

ex:SubmitterShape
rdfs:subClassOf schema:Person;
rdfs:comment "A submitter is a person that has at least one email address."
;
sh:property [
sh:predicate schema:email ;
sh:minCount 1 ;
] .

to me, this is simple, modular, and uses standard terminological
specialization. It also lets me define other shapes on ex:Issue *or* on
ex:IssueShape.

m.


Michel Dumontier, PhD
Associate Professor of Medicine (Biomedical Informatics)
Stanford University
http://dumontierlab.com

On Thu, Apr 23, 2015 at 5:26 PM, Holger Knublauch <holger@topquadrant.com>
wrote:

>
>
> On 4/24/15 10:15 AM, Michel Dumontier wrote:
>
> Hi Holger,
>  I think a key aspect of SHACL that would be nice to highlight is how
> shapes can *specialize* existing Classes/Shapes. Example 1 shows a simple
> example where the ex:Issue is declared as an rdfs:Class, but is
> simultaneously specialized as a  Shape due to its associated SHACL
> constraint. Can we, for the sake of simplicity and modularity, show how a
> shape can be applied to an existing class? We could then demonstrate the
> modularity by showing that we could have two shapes that specialize the
> class.  How is exactly would that be done?
>
> In my current proposal, if a shape is supposed to participate in a
> specialization relationship, then it should be declared as an rdfs:Class.
> There is no real downside from a Shape perspective - it is still a shape
> even if it is (also) a class. Having two parallel specializations
> hierarchies would IMHO lead to chaos and unnecessary overhead.
>
>
>   I also wonder why sh:valueType doesn't just point directly to one value
> - in this case a shape description that specializes schema:Person - e.g.
> ex:SubmitterShape. That would eliminate sh:shape, a seemingly redundant
> predicate to specify the value type.
>
>
> sh:valueType restricts the rdf:type triple that is stored in the model.
> sh:shape only defines additional constraints that these values also need to
> have (possibly in addition to being an instance of schema:Person). sh:shape
> actually walks into the nested properties of the given shape, while
> sh:valueType only scratches the surface and only looks for the rdf:type
> triple. Since these are very different use cases, I believe we still need
> both.
>
> Holger
>
>
>  Taking this approach would help users see a simpler, modular design. It
> also actually follows what we already do with our SADI semantic web
> services (where service inputs are specializations of ontology-defined
> classes, and outputs are specializations of service inputs).
>
>  m.
>
>  Michel Dumontier, PhD
> Associate Professor of Medicine (Biomedical Informatics)
> Stanford University
> http://dumontierlab.com
>
> On Thu, Apr 23, 2015 at 4:18 PM, Holger Knublauch <holger@topquadrant.com>
> wrote:
>
>> In an attempt to make the discussion about ISSUE-23 [1] a bit more
>> specific, I would like to suggest the following design. I have experimented
>> with this design for a while and it appears to work nicely - both from an
>> implementation perspective and user experience. My current draft [2] uses
>> this design in its examples.
>>
>> In this proposal, the base class is sh:Shape, which carries the system
>> properties to define constraints, i.e. sh:constraint, sh:property and
>> sh:inverseProperty. sh:Shape can be instantiated and used by itself. To
>> instruct a SHACL engine, the property sh:nodeShape is used to link a
>> resource with its sh:Shape(s) that it is supposed to have. This design
>> pattern is especially suitable for people who want to avoid any conflicts
>> between existing RDFS data models and constraint checking.
>>
>> In the context of SHACL, rdfs:Class is declared as a rdfs:subClassOf
>> sh:Shape, which means that any class can play the role of a Shape, and a
>> Class can have constraints attached to it. Furthermore the rdf:type
>> property is used by the SHACL engine to link instances with their class
>> shapes, in the same way that sh:nodeShape is used. As a consequence, we
>> have a natural implementation of specialization - rdfs:subClassOf is used
>> to express sub-shape relationships.  This design pattern is especially
>> suitable for people who want to naturally build upon the data models that
>> already exist, and existing rdf:type triples.
>>
>> I believe this design produces a very attractive user-facing syntax (no
>> bloating extra triples) while maintaining a very good level of flexibility
>> and backwards compatibility. Existing RDFS/OWL ontologies and their
>> instances can be incrementally enhanced with SHACL constraints.
>>
>> I would welcome specific, practice-oriented criticism of this design.
>>
>> Thanks,
>> Holger
>>
>> [1] http://www.w3.org/2014/data-shapes/track/issues/23
>> [2] http://w3c.github.io/data-shapes/shacl/
>>
>>
>>
>
>