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

Holger,

oslc:instanceShape was intended for use with Linked Data. The URI of
the graph is both a node in the graph and an identifier of a web
document that you can HTTP GET. In that sense, the graph URI node is
distinguished and may be the subject of an oslc:instanceShape triple.
ISSUE-44 appears to refer to a different situation. Thanks for the
clarification.

-- Arthur

On Thu, Apr 16, 2015 at 5:12 PM, Holger Knublauch
<holger@topquadrant.com> wrote:
> Arthur,
>
> you seem to assume that a graph only contains a single root resource? That
> would just be a special case of named graphs. My use cases are
>
> - if someone opens a file in an editor, the system needs to be able to
> quickly figure out which other graphs need to be included, to build a union
> graph that can be queried by the editing tool
>
> - same for constraint checking - if someone validates a whole graph, we need
> to know which shapes to collect, where the required SHACL templates are
> defined etc. Following all references in linked data style is often not
> feasible and not the best approach (although this is another option that we
> could support too).
>
> Holger
>
>
>
>
> On 4/17/15 6:50 AM, Arthur Ryman wrote:
>>
>> On Thu, Apr 16, 2015 at 4:34 PM, Holger Knublauch
>> <holger@topquadrant.com> wrote:
>>>
>>> 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.
>>
>> Holger,
>>
>> Your writeup of ISSUE-44 says:
>> "1) sh:include - points from a graph (e.g. of instances) to other
>> graphs (e.g. of class definitions)"
>>
>> If you are pointing from an instance graph to the shape that describes
>> it, then in OSLC you use oslc:instanceShape. This is like on XML
>> document pointing to an XML Schema. Is that what sh:include is for? If
>> not, I think your writeup is misleading.
>>
>> -- Arthur
>
>

Received on Thursday, 16 April 2015 21:28:57 UTC