- From: Holger Knublauch <holger@topquadrant.com>
- Date: Fri, 17 Apr 2015 06:34:13 +1000
- To: "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
On 4/17/15 2:31 AM, Arthur Ryman wrote: > Holger, > > OSLC Resource Shapes supports this requirement through the > oslc:instanceShape property. I believe that your proposed sh:include > property serves the same purpose as oslc:instanceShape. Please > confirm. oslc:instanceShape looks like sh:nodeShape [1] to me. As far as I understand the OSLC spec, sh:include/sh:library would be closer to oslc:resourceShape. Instead of linking individual resources, my goal is to be able to link a graph with another graph containing the class and shape definitions that it relies on. If you have a pure Linked Data architecture where everything is resolvable by URLs, this may not sound too important, yet for application modularity and editing tools this is important, in our experience. Holger [1] https://w3c.github.io/data-shapes/shacl/#shape-selection-based-on-sh-nodeshape > > OSLC strategy is to replace Resource Shapes with SHACL. If SHACL is > missing the equivalent of oslc:instanceShape, then OSLC will have to > add it as an extension. > > -- Arthur > > On Wed, Apr 15, 2015 at 7:08 PM, Holger Knublauch > <holger@topquadrant.com> wrote: >> On 4/16/15 2:13 AM, Peter F. Patel-Schneider wrote: >>> 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? >> >> Yes. Applications could ignore the default shapes associated with a >> published data model. Simon also suggested to make the graph linkage >> context-specific, and this may make sense too. The point however remains >> that there is *one* public internet and if we want to encourage meaningful >> sharing of information on that web then the authors of data models should be >> allowed to point at the formal definitions of the semantics that they >> intended to be used for these models so that generic agents can discover >> linked data. >> >>>> 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. >> >> I argue that explicit inclusion is necessary and helpful, and should be >> uncritical as long as make clear that this is just the default >> interpretation. We should IMHO not rely on owl:imports, because >> >> - we don't have any other dependency on OWL, why complicate everything? >> - owl:imports have a specific meaning in OWL that is different from the >> intended meaning in SHACL. It's the same argument why we don't simply >> reinterpret owl:Restrictions in SHACL. >> - owl:imports does not distinguish between the different use cases addressed >> by sh:include vs. sh:library - it would bring in all Shape definitions as >> data. >> >>>> 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. >> >> That is true, and we could indeed not say anything about this. Yet I believe >> this leaves too many questions unanswered, and the market will produce its >> own incompatible solutions to this problem (e.g. some tools may indeed use >> owl:imports, while others do follow-your-node, while others will introduce >> mytool:imports). Adding the two proposed properties is a low hanging fruit >> that the WG can easily deliver. >> >> Thanks, >> Holger >> >>
Received on Thursday, 16 April 2015 20:34:46 UTC