On 10/6/2015 9:39, Holger Knublauch wrote:
> I think what we need is a careful analysis of less than a handful of
> set-ups that we can reasonably support, and put best practice recipes
> for those set-ups into our documentation. So I retract my previous
> comments, and now believe that we indeed need to do something here
> with this ticket.
Attached are two images for two graph design patterns for SHACL.
Option A is the simple case where shapes graph = data graph, and this
logical graph contains shapes, classes and data (instances). The
advantage of this design is the simplicity - no need to worry about
complex setups, just throw everything together. The disadvantage is
performance because the system may be seeing unnecessary triples from
the shapes graph, and even validate them too.
Option B is a case where shapes graph and data graph are distinct.
However, since the class definitions (esp the subClassOf triples) are
needed as part of the data traversal and also to link shapes with
classes, the classes subgraph is shared between both worlds.
Are there other options?
Note that I could have added various links to the diagrams, e.g. to show
rdfs:subClassOf, rdf:type and sh:scopeClass triples. I didn't do this to
keep the diagrams simple.
I could have also included owl:imports and sh:shapesGraph links between
the boxes, but these are optional as programmers may arbitrarily
rearrange the various subgraphs even without those triples.
Would it make sense to include something along those lines into the spec?
Holger
