- From: Holger Knublauch <holger@topquadrant.com>
- Date: Thu, 16 Apr 2015 09:08:37 +1000
- To: public-data-shapes-wg@w3.org
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 Wednesday, 15 April 2015 23:09:10 UTC