Re: shapes-ISSUE-44 (Graph dependencies): How to express dependencies between graphs [SHACL Spec]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 04/14/2015 11:10 PM, RDF Data Shapes Working Group Issue Tracker wrote:
> shapes-ISSUE-44 (Graph dependencies): How to express dependencies between
> graphs [SHACL Spec]
> 
> http://www.w3.org/2014/data-shapes/track/issues/44
> 
> Raised by: Holger Knublauch On product: SHACL Spec
> 
> Graphs that are published in a dataset or the "open" web often rely on
> definitions in other graphs.  OWL has a property owl:imports to express
> that when an OWL file is parsed then the axioms from imported graphs
> should also be included (for inferencing etc). RDF(S) does not have such
> a facility.

Bad RDF(S).  Good OWL.  :-)

> Although many applications may take complete control over what graphs are
> needed for shape validation, it would be useful to be able to say that my
> published graph needs definitions from another given graph, and to point
> from a graph to the shapes graph that should be used for validation *by
> default*.

By default?  As in it could be overridden?

> A possible design would include two properties 1) sh:include - points
> from a graph (e.g. of instances) to other graphs (e.g. of class
> definitions) 2) sh:library - points from a data graph to a graph with
> shapes definitions
> 
> So the main question here is whether SHACL should have such properties at
> all (and possibly a class sh:Graph to represent the graph itself). I
> anticipate that some people will argue that adding such information into
> the graph itself limits its potential for reuse, but in many cases there
> are pretty obvious default interpretations that should be followed, esp
> if shapes are linked with classes.

Given that RDF(S) doesn't have this facility, why should SHACL?  Given that
OWL does have this facility, why should SHACL?  Either explicit inclusion is
unnecessary, a la RDF(S), so SHACL doesn't need it, or explicit inclusion
can be provided by using the OWL facility.  In all cases, we don't need to
worry about it.

> If the WG decides against such properties, we need to at least explain
> users how they are supposed to publish any data that is discoverable by
> generic constraint checking applications.

Well, any primer we produce should have a section on how SHACL is used.
That could include simple examples and more complex examples.  Whether there
is any attempt to show where the data comes from is, I think, going to be a
matter of taste.  In the end, I don't think that it is absolutely necessary
to say anything about the source of the data and shapes beyond RDF graphs
and datasets.


peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJVLo5FAAoJECjN6+QThfjz54IIAMjGs6eUVZ3RXzf+hXPXbMlI
S/AJjH2d9qJg4Qy5MHbdieUhXn71K2kd0qVjvXjG+ui/iJg1bg/YKIKcNZFF/b/Q
EAQ/GDqHpYTQA8Xdvbf7pDiixWz/odonYGbZOMlSeimVXV7L2gjDc7l2Vr4aV0cG
Y0v670oUCVuGJpNgXOHJWx4JkYX7KzccfxiqmGU5pNl/XhGxuyeP+tTJz4XakgyL
tpjmofbG/bjQD9ojZUxCBDi0Ljh7D3rAT2b2uOxHkoXbZu23f3Zm+RF5kv5r8/eG
jhciefp2fWavGhj+pZFLKSg1huOdcmmDkvz6pdvapfxUZo7dtl81H1e7XCP6crI=
=ZcXO
-----END PGP SIGNATURE-----

Received on Wednesday, 15 April 2015 16:15:01 UTC