W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > March 2016

Re: type and instance and subclass in SHACL documents

From: Tom Johnson <johnson.tom@gmail.com>
Date: Mon, 14 Mar 2016 13:27:33 -0700
Message-ID: <CAJeHiNG+Qvydn-rxjP+4FcEmirWTnCKwVNuG0z-iKiyLA5xstw@mail.gmail.com>
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>
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
  - 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>

> 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
> ?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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:30 UTC