- From: Holger Knublauch <holger@topquadrant.com>
- Date: Tue, 8 Mar 2016 08:36:19 +1000
- To: public-data-shapes-wg@w3.org
On 8/03/2016 1:51, Peter F. Patel-Schneider wrote: > On 03/06/2016 08:46 PM, Holger Knublauch wrote: >> Thanks for the feedback, Peter. I have tried to address it here: > [...] > >> On 7/03/2016 6:59, Peter F. Patel-Schneider wrote: >>> General > [...] > >>> It is not sufficient to say in 1.1 that SHACL has unique versions of types >>> and instances. These notions are in very widespread use. Each time that >>> SHACL deviates from the common, accepted W3C practice it should be called >>> out, e.g., "SHACL type" or "SHACL instance". >> I hope this doesn't need to be repeated each time as this may render the >> document harder to read. Furthermore, the terms "SHACL type" and "SHACL >> instance" would first need to be formally defined too. >> >> Instead, I suggest we should define what "type", "instance" and "subclass" >> mean in the remainder of the document. I have put a corresponding terminology >> block at the end of section 1.1 > This is inadequate. > > SHACL uses RDF graphs and RDFS vocabulary. There are already definitions of > type and instance and subclass that come from RDF and RDFS. SHACL needs to > differentiate its version of type and instance and subclass from these > dominant notions and this can only be reliably done by qualifying them each > time they appear in formal SHACL documents. > > Alternatively the SHACL document could use different words for these > relationships or could restrict the inputs that it handles so that it uses the > dominant versions of type and instance and subclass. My interpretation of the situation is - RDF and RDFS define the IRIs of vocabulary terms rdf:type and rdfs:subClassOf - terms like subclass, type and instance already existed before RDFS and carry intuitive meaning - there is no need to over-complicate a situation that is already clear to most readers The only difference between our definitions of the terms is that you think that subclassing must always require inferences (domain, ranges etc). I believe these concepts are orthogonal. Some rdfs:subClassOf triples may be the result of inferencing, but it doesn't matter to SHACL where they came from. As long as we make this clear in the beginning, I hope we can keep the document intuitive and not over-complicate it. Holger
Received on Monday, 7 March 2016 22:36:55 UTC