- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Thu, 12 May 2016 07:44:54 -0700
- To: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org>
Thanks, Dimitris. And I note that in 2.1.2 it says: "Note that, according to the SHACL instance definition, all the rdfs:subClassOf declarations must exist in the data graph." which I hadn't noticed before. So the data graph must have the needed subclass triples. However, the section doesn't address the possibility of selecting all subclasses of a class, so the statement seems out of place. kc On 5/11/16 10:41 PM, Dimitris Kontokostas wrote: > Hi Karen, > > SPARQL is used as definition in sections 2.1, 2.2 & section 3 > > On Thu, May 12, 2016 at 5:22 AM, Karen Coyle <kcoyle@kcoyle.net > <mailto:kcoyle@kcoyle.net>> wrote: > > The SHACL document says, in the introduction: > > "However, SPARQL is not required for the implementation of the SHACL > Core language." > > Our decision was to use SPARQL as the formal definition of SHACL > functions "where possible" but is it truly reasonable to provide > this functionality and NOT require SPARQL? > > Before we get to that point though, could someone point out the > operations in SHACL that would logically make use of SPARQL query > (with or without the SPARQL "rdfs:subClassOf*"). I'm trying to > understand where it fits in. > > Thanks, > kc > > > On 5/11/16 3:25 PM, Holger Knublauch wrote: > > A precise definition can be achieved via SPARQL, e.g. > rdf:type/rdfs:subClassOf*. The subclass relationship and the > additional > type relations are computed on the fly as part of the queries. > Using the > term inferencing here is unnecessary and potentially harmful, > because > inferencing is typically understood to produce additional "inferred" > triples from those that are "asserted". No new triples are needed. > > Holger > > > On 12/05/2016 8:16, Martynas Jusevičius wrote: > > So how do you express that form of subclassing? There surely > must be a > more precise and formal way than a sentence of prose. Even > if it's not > RDFS inferencing, it should be possible to define a > different kind of > inferencing for RDF, for example OO-like. > > It's not that SHACL implementations will need reasoners, their > implementations just need to deliver results that are > consistent with > the official definition. > > Hint: RDF rules for definition. > > On Thu, May 12, 2016 at 12:03 AM, Holger Knublauch > <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote: > > SHACL doesn't do RDFS inferencing. SHACL uses a trivial > and intuitive > form > of subclassing that had been invented long before RDFS, > and is > well-established in OO systems. The fact that RDFS also > reinvented a > similar > technique (and added some other inferencing rules) is > orthogonal. > RDFS does > not have any rights to block these concepts or the terms > for all future > technologies. > > The SHACL spec doesn't use the term inferencing except > to state that it > doesn't rely on inferencing. Even if this WG decides to > use other > terms than > "instance", "type" and "subclass", the effect to the end > user will be > exactly the same. It's just a matter of clarity and > politics. > > Holger > > > > On 11/05/2016 23:30, Peter F. Patel-Schneider wrote: > > But SHACL does do RDFS inferencing in the data > graph. In > particular, the > sh:class depends in RDFS inferencing, namely > inference rule rdfs11 from > https://www.w3.org/TR/rdf11-mt/#rdfs-entailment. At > one time sh:class > also > depended on inference rules rdfs4a and rdfs4b as > well as the RDFS axiom > rdf:first rdfs:domain rdf:List . > > So saying that SHACL doesn't do RDFS inferencing in > the data graph is > incorrect. > > > Simmilarly SHACL does RDFS inferencing in the shapes > graph when it > accepts > ex:s1 as a shape in > > ex:Shape rdfs:subClassOf sh:Shape . > ex:s1 rdf:type ex:Shape ; > sh:scopeClass ex:Person ; > sh:constraint [ rdf:type sh:NodeConstraint ; > sh:nodeKind sh:IRI ] . > > (This appears to be an acceptable SHACL shape, based > on the SHACL > specification.) > > > Of course, SHACL does not do *complete* RDFS > inferencing. In > particular, > there is no SHACL shape in > > ex:subClassOf rdfs:subPropertyOf rdfs:subClassOf . > ex:Shape ex:subClassOf sh:Shape . > ex:s1 rdf:type ex:Shape ; > sh:scopeClass ex:Person ; > sh:constraint [ rdf:type sh:NodeConstraint ; > sh:nodeKind sh:IRI ] . > > > peter > > > > > On 05/11/2016 01:58 AM, Dimitris Kontokostas wrote: > > I am reopening this old thread which is more > related to the other open > discussions we have atm. > > Looking at Tom Baker's emails and in particular > [1] (the first three > paragraphs under discussion) I was wondering if > this can be a way > forward > > in particular say that SHACL uses rdf and rdfs > terms but a shacl > processors > takes two immutable graphs (shapes & data) and > performs no rdfs > inferencing on > the graphs at all > any inferencing must be performed as a > preprocessing step and is > out of > scope > for shacl > In there we define the term "shacl instance" > which is used in only two > places > in the spec, in sh:classScope and sh:class and > no-where else > if people believe that we should disallow > optional rdf:type statements > (e.g. > for sh:property) I do not mind if this can > unblock the current > situation > Peter, would using the terms instance, class or > subClassOf be fine > under > these > conditions? > > (I am also in favor of dropping sh:entailment btw) > > Any comments on this? > > Best, > Dimitris > > [1] > https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1605&L=DC-ARCHITECTURE&P=3148 > > > On Tue, Mar 22, 2016 at 12:56 AM, Holger Knublauch > <holger@topquadrant.com > <mailto:holger@topquadrant.com> > <mailto:holger@topquadrant.com > <mailto:holger@topquadrant.com>>> wrote: > > This is becoming a long long thread about > what is an entirely > editorial > matter. I don't think it deserves the > urgency. I also do not > agree > that we > are misusing these terms at all. I > believe to make progress > we could > > a) try to find alternative terms (Peter > suggested "SHACL > instance" > etc, > but it could also be "is-a") > b) follow the lead of what other, similar > W3C specs are doing > c) define the terms in the beginning and > then use them as <span > class="term">instance</span> so that the > reader knows that we > use > that > definition. That would be my preferred > solution. > > Looking at the OWL 2 spec [1] the term > "instance" is used in > many > different contexts, without even being > defined: > - "Each OWL 2 ontology represented as an > instance of this > conceptual > structure" > - "if an individual /a:Peter/ is an > instance of the class > /a:Student/, > and /a:Student/ is a subclass of > /a:Person/, then from the OWL 2 > semantics > one can derive that /a:Peter/ is also an > instance of > /a:Person/." > - "Instances of the UML classes" > - Class expressions represent sets of > individuals by formally > specifying > conditions on the individuals' > properties; individuals > satisfying > these > conditions are said to be /instances/ of > the respective class > expressions" > - ... > > Not only does OWL use the term "instance" > inconsistently but > even > changes > the RDF term by applying additional OWL > semantics. RDFS does not > have the > monopoly on these terms. > > The problem is not our use of these terms > but the misleading > section > 1.1 > that needs to be replaced. I liked a > previous proposal from > Dimitris, > along the lines of "SHACL is based on > pattern matching like > SPARQL. > Inferencing is not required but there is > no harm if > inferencing is > activated (be it OWL or RDFS > inferencing)". Then define the > terms > similar > to what we currently have at the end of > section 1.1. And > that's it. > > Holger > > > > https://www.w3.org/TR/owl2-syntax/ > > > On 22/03/2016 4:15, Peter F. > Patel-Schneider wrote: > > I don't think that this helps at > all. In fact, all that it > does is > further > obfuscate the issue. The issue is > that the wording needs to be > clear that in > > sh:shape rdf:type my:Shape . > my:subClassOf rdfs:subPropertyOf > rdfs:subClassOf. > my:Shape my:subClassOf sh:Shape . > > my:Shape is not a SHACL shape, but > that in > > sh:shape rdf:type my:Shape . > my:Shape rdfs:subClassOf sh:Shape . > > it is. > > There are many cases where the SHACL > notion of subclass, > instance, > typing, > etc., diverges from the common > definition of these notions. > > peter > > > On 03/21/2016 02:05 AM, Dimitris > Kontokostas wrote: > > Hi Peter, I did some research on > other w3c specs regarding the > term instance. > > if we changed occurrences of > instance from e.g. > "shapes are the instances of > sh:Shape" to > "sh:Shape is the class of all shapes" > would this be fine from your side? > > Some cases like sh:class and > sh:classScope would need extra > care > of course. > > On Mon, Mar 14, 2016 at 12:24 AM, > Peter F. Patel-Schneider > <pfpschneider@gmail.com > <mailto:pfpschneider@gmail.com> > <mailto:pfpschneider@gmail.com > <mailto:pfpschneider@gmail.com>> > <mailto:pfpschneider@gmail.com > <mailto:pfpschneider@gmail.com>> > <mailto:pfpschneider@gmail.com > <mailto:pfpschneider@gmail.com>>> > wrote: > > Even in this situation I > think that "instance" in the > rest of > the document > needs to be qualified. Some > readers of the document > will know > about RDFS > instance and will need to be > continually reminded that the > meaning that they > know for "instance" is not > being used in this document. > > peter > > > > -- > Dimitris Kontokostas > Department of Computer Science, University of > Leipzig & DBpedia > Association > Projects: http://dbpedia.org, > http://rdfunit.aksw.org, > http://aligned-project.eu > <http://aligned-project.eu/> > Homepage:http://aksw.org/DimitrisKontokostas > Research Group: AKSW/KILT > http://aksw.org/Groups/KILT > > > > > > > -- > Karen Coyle > kcoyle@kcoyle.net <mailto:kcoyle@kcoyle.net> http://kcoyle.net > m: 1-510-435-8234 > skype: kcoylenet/+1-510-984-3600 <tel:%2B1-510-984-3600> > > > > > -- > Dimitris Kontokostas > Department of Computer Science, University of Leipzig & DBpedia Association > Projects: http://dbpedia.org, http://rdfunit.aksw.org, > http://aligned-project.eu > Homepage: http://aksw.org/DimitrisKontokostas > Research Group: AKSW/KILT http://aksw.org/Groups/KILT > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Thursday, 12 May 2016 14:45:35 UTC