- From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Date: Thu, 12 May 2016 08:41:41 +0300
- To: Karen Coyle <kcoyle@kcoyle.net>
- Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org>
- Message-ID: <CA+u4+a1PCZ5ZXJ8Cp4_f5Ka-tXfkRc3x-t25i_OVAbeLg6aZYQ@mail.gmail.com>
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> 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> 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>> 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>> >>>>>>>> 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 http://kcoyle.net > m: 1-510-435-8234 > skype: kcoylenet/+1-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
Received on Thursday, 12 May 2016 05:42:38 UTC