Re: ISSUE-23: A specific proposal

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

>  On 4/24/2015 10:37, Michel Dumontier wrote:
>
> Holger,
>   You misunderstand, I do not want two parallel specialization hierarchies
> - I want one.
>
>
> Glad to hear that!
>
>
>  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.
>
>
> This is possible in principle (assuming ex:IssueShape rdf:type
> rdfs:Class), but the question then becomes what rdf:type do the instances
> have? In the example they are just instances of ex:Issue, so the
> constraints at IssueShape would not apply to them by default, unless you
> also add sh:nodeShape triples to link the Issues with the IssueShape (or
> have some external mechanism to map this).
>
> I may have misunderstood what you try to get across? If you want to group
> together some constraints, or separate class and shape definitions, you
> could have it the other way around: ex:Issue rdfs:subClassOf ex:IssueShape,
> and have ex:IssueShape as an "abstract" class.
>
> Holger
>
>  right, i'm so used to OWL classification, that's how i formulated it to
make sense initially. but in the approach you're suggesting now, one
asserts that all instances of ex:Issue are instances of ex:IssueShape, and
you check that they satisfy the constraints - throwing an error if not.
The worry I have is that if you just have a simple SPARQL query you
trivially "know" that every instance of ex:Issue is an instance of
ex:IssueShape.

if this inheritance behavior is similarly undesirable, then i don't see how
you can't keep shapes and classes from being naturally disjoint different...

m.