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

Just for clarification:

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

The graph that should be affected by shapes, i.e. should be considered 
for validation?

simon

---
DDipl.-Ing. Simon Steyskal
Institute for Information Business, WU Vienna

www: http://www.steyskal.info/  twitter: @simonsteys

Am 2015-04-15 08:10, schrieb RDF Data Shapes Working Group Issue 
Tracker:
> 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.
> 
> 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*.
> 
> 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.
> 
> 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.

Received on Wednesday, 15 April 2015 06:33:18 UTC