- From: Michel Dumontier <michel.dumontier@stanford.edu>
- Date: Thu, 23 Apr 2015 18:04:56 -0700
- To: Holger Knublauch <holger@topquadrant.com>
- Cc: RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
- Message-ID: <CALcEXf6=Foy8+Rms5wuWWit_JC-S-WXH8DMm+4i=KrLfbjjSag@mail.gmail.com>
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.
Received on Friday, 24 April 2015 01:05:46 UTC