- From: Tom Johnson <johnson.tom@gmail.com>
- Date: Mon, 14 Mar 2016 13:27:33 -0700
- To: Irene Polikoff <irene@topquadrant.com>
- Cc: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, Karen Coyle <kcoyle@kcoyle.net>, RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
- Message-ID: <CAJeHiNG+Qvydn-rxjP+4FcEmirWTnCKwVNuG0z-iKiyLA5xstw@mail.gmail.com>
I'm not sure SPARQL is needed, but some formal exposition is critical. The text at the end of 1.1 in the current editor's draft is a start, but I don't think it's sufficiently formal: - it doesn't answer the questions about where these triples must appear (when in the data graph vs. the shapes graph); - it's not necessarily clarifying with respect to the text directly above it; - and it seemingly doesn't apply to all appearances of the defined terms in the text[0]. - the most obvious exception being "The RDF Schema vocabulary defines various terms to model domains in terms of classes and instances.". To be clear: I think the move to avoid reliance on RDFS semantics in defining SHACL's behavior is a good one. With significant editorial work, I think there's a way to make the document communicate the simplifying effects of this decision precisely and elegantly. It's just not there yet. I tend to think this effort would be helped by not overloading RDFS terminology; but forcefully presented definitions followed by consistent use throughout would serve, too. In general, I don't think it's sufficient to appeal to the intuitive meaning of *subclass*, *type* and *instance*. In my understanding, SHACL's use of these terms is explicitly *not* following from the intuitive ones--instead being based on the presence of specific triple patterns in specific graphs. I think, at this point, I've probably said my piece; I'll leave the rest for the WG to hammer out. Hopefully this has been helpful. - Tom On Mon, Mar 14, 2016 at 11:45 AM, Irene Polikoff <irene@topquadrant.com> wrote: > These questions are probably more to the editors rather than to me and may > help them in improving clarity of the writing. Having said this, with the > natural language, there is always an opportunity for slightly different > interpretations. May be more SPARQL needs to be included to ensure > precision - such as > > SELECT ?shape > WHERE { > ?shapeClass rdfs:subClassOf* sh:Shape. > ?shape a sh:Shape. > } > > I thought that the transitivity of rdfs:subClassOf was applied universally > in the spec, but I have not examined it focusing specifically on trying to > confirm this. > > Irene > > > From: Tom Johnson <johnson.tom@gmail.com> > Date: Monday, March 14, 2016 at 12:20 PM > > To: Irene Polikoff <irene@topquadrant.com> > Cc: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, Karen Coyle < > kcoyle@kcoyle.net>, RDF Data Shapes Working Group < > public-data-shapes-wg@w3.org> > Subject: Re: type and instance and subclass in SHACL documents > > On Mon, Mar 14, 2016 at 10:44 AM, Irene Polikoff <irene@topquadrant.com> > wrote: > >> Tom, >> >> I read Section 2[0] as: >> >> For a resource to be understood as a shape by the SHACL engine, it must >> be a subject of a triple with rdf:type predicate and the object either >> sh:Shape or one of its subclasses. >> > > That seems like the intuitive reading, but some details are fuzzy. MUST > that rdf:type predicate be in the shapes graph? When does a class count as > a subclass of sh:Shape? Guessing: "if and only if it has a triple with > predicate rdfs:subClassOf in the shapes graph"; but that's not stated > anywhere I can see. > > ex:subShape rdfs:subClassOf sh:Shape . > ex:subSubShape rdfs:subClassOf sh:subShape . > ex:PersonShapeOne a sh:subShape . > ex:PersonShapeTwo a sh:subSubShape . > > Does my implementation need to recognize both PersonShapes as shapes? On > a strict reading (even taking your suggested interpretation for granted), > ex:PersonShapeTwo is not a shape. Is my implementation non-conforming if > it is recognized? > > Transitivity of rdfs:subClassOf applies in some places in the spec, and > not in others; does it apply here? It's somewhat clear that domain and > range inference don't apply, but that could use some clarification, too. > Possibly, the exclusion of those is meant to be limited to the *evaluation > *of shapes, rather than their definitions. > > ex:maybeShape sh:scopeClass foaf:Person ; > sh:property [ > sh:predicate foaf:name ; > sh:minCount 1 . > ] . > > Is my implementation non-conforming if it recognizes ex:maybeShape as a > shape? My guess is yes, but then domains and ranges are declared in the > SHACL Turtle (I think; I can't actually find a current .ttl to verify > this). Contrary to a claim in another part of this thread, my experience is > that RDF authors frequently elide explicit definitions in exactly this way; > especially when writing by hand as many are likely to do with SHACL. It > would hopefully be clear whether this is a shape will be recognized and > evaluated. > > (As a largely unrelated aside, Section 12 seems to say that using RDFS > entailment effects only the data graph. There should probably be an > explicit example showing that entailment doesn't effect recognition of > shapes.) > > Again, further (and odder) examples can be dreamt up by directly > referencing terms from the rdf/rdfs namespaces; in the manner of Peter's > example. > > So, exactly the same definition of an instance as every place else in the >> spec. I would have thought that this information most likely to be in the >> shapes graph as it is part of the shape definition. As in, for example: >> > > The bulk of my point is that "the same definition as every place else in > the spec" is not at all clear to me. There is an interpretation that feels > natural (and I think it's basically the same one that feels natural to you) > but two naive implementations built on an equivalent reading will probably > have different answers to some of the questions above. > >> ex:PersonShape >> a sh:Shape ; >> sh:scopeClass foaf:Person ; >> sh:property [ >> sh:predicate foaf:name ; >> sh:minCount 1 >> ] . >> >> >> >> Irene >> > > - Tom > > >> From: Tom Johnson <johnson.tom@gmail.com> >> Date: Sunday, March 13, 2016 at 11:10 PM >> To: Irene Polikoff <irene@topquadrant.com> >> Cc: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, Karen Coyle < >> kcoyle@kcoyle.net>, RDF Data Shapes Working Group < >> public-data-shapes-wg@w3.org> >> Subject: Re: type and instance and subclass in SHACL documents >> >> To drive the point home: some cases are a significantly muddy. See, for >> example, Section 2[0]: >> >> shapes are instances of the class sh:Shape (or subclasses of sh:Shape >> ). >> >> Here, I think we mean to say an RDF(S) instance(?). Using the only >> alternate definition I can find in SHACL, there would need to be a triple >> of the pattern `?s rdf:type sh:shape` in the *data* graph for a resource >> to be a shape. In either case, it's unclear whether subclass transitivity >> applies here. >> > > > > -- > -Tom Johnson > -- -Tom Johnson
Received on Monday, 14 March 2016 20:28:43 UTC