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

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 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 16:31:46 UTC