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