Re: type and instance and subclass in SHACL documents

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

> 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 <>
> Date: Monday, March 14, 2016 at 12:20 PM
> To: Irene Polikoff <>
> Cc: "Peter F. Patel-Schneider" <>, Karen Coyle <
>>, RDF Data Shapes Working Group <
> Subject: Re: type and instance and subclass in SHACL documents
> On Mon, Mar 14, 2016 at 10:44 AM, Irene Polikoff <>
> 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 <>
>> Date: Sunday, March 13, 2016 at 11:10 PM
>> To: Irene Polikoff <>
>> Cc: "Peter F. Patel-Schneider" <>, Karen Coyle <
>>>, RDF Data Shapes Working Group <
>> 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