Re: ISSUE-65: type and instance and subclass in SHACL documents

This is one part of the divergence, but there are quite a few more bits
involving the axiomatic RDFS, and RDF, triples, which are also not used in SHACL.

One way forward would be to remove "type" and "instance" from SHACL.

peter


On 03/09/2016 11:22 PM, Dimitris Kontokostas wrote:
> Peter may correct me if I am wrong but the problem comes from the relation of
> rdf:type / rdfs:subClassOf* and the definition of  subClass & subProperty in RDFS
> if someone defines ex:subClassOf rdfs:subPropertyOf rdfs:subClassOf and uses
> ex:subClassOf in his relations SHACL will not be able to identify these relations.
> This is more or less what the biggest part of section 1.1 is about.
> 
> I think removing it completely will create more confusion. I would suggest to
> postpone this until we get close candidate rec and then see how this can be
> shortened.
> 
> On Thu, Mar 10, 2016 at 7:47 AM, Holger Knublauch <holger@topquadrant.com
> <mailto:holger@topquadrant.com>> wrote:
> 
>     I would also like to know the answer to Irene's questions. If not, then I
>     believe we can basically delete the contentious section 1.1. All we need
>     to state is that SHACL does not require full RDFS inferencing. Section 1.1
>     has already created a lot of noise
> 
>     https://twitter.com/tombaker/status/694516400497545216
>     https://twitter.com/metazippy/status/659379807784992768
> 
>     I have filed this email under ISSUE-65 so that we don't forget about it.
> 
>     Holger
> 
> 
>     On 8/03/2016 9:00, Irene Polikoff wrote:
> 
>         rdfs:subClassOf is defined as follows:
> 
>         "The property rdfs:subClassOf is an instance of rdf:Property that is used
>         to state that all the instances of one class are instances of another.
>                         A triple of the form:
>                        
>            C1 rdfs:subClassOf C2
> 
>         states that C1 is an instance of rdfs:Class, C2 is an instance of
>         rdfs:Class and C1 is a subclass of C2. The rdfs:subClassOf property is
>         transitive."
> 
>         This definition doesn¹t really require for any inferred triples to be
>         present.
> 
> 
>         Is there anything in SHACL¹s use of rdfs:subClassOf that is contradictory
>         to the above definition?
> 
>         The only wording close to the definition of the word ³instance² that I
>         found in the specs is:
> 
>         "The members of a class are known as instances of the class.²
> 
> 
>         Finally, rdf:type is described in the RDFS spec as
> 
>         "The rdf:type property may be used to state that a resource is an instance
>         of a class.²
> 
>         RDF specs don¹t talk about rdf:type.
> 
> 
>         Is there anything in SHACL¹s use of the word ³instance" or of rdf:type
>         that contradicts this definition? If so, what is it?
> 
> 
> 
>         Irene Polikoff
> 
> 
> 
> 
> 
> 
>         On 3/7/16, 5:36 PM, "Holger Knublauch"<holger@topquadrant.com
>         <mailto:holger@topquadrant.com>>  wrote:
> 
>             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
> 
> 
> 
> 
> 
> 
> 
> -- 
> Dimitris Kontokostas
> Department of Computer Science, University of Leipzig & DBpedia Association
> Projects: http://dbpedia.org, http://rdfunit.aksw.org,
> http://http://aligned-project.eu <http://aligned-project.eu/>
> Homepage:http://aksw.org/DimitrisKontokostas
> Research Group: AKSW/KILT http://aksw.org/Groups/KILT
> 

Received on Friday, 11 March 2016 17:38:03 UTC