Re: Proposal to close ISSUE-3 and ISSUE-44

Hi Arthur,

you have described your OSLC use case, where the mapping between nodes 
and shapes is somehow determined outside of the control of SHACL. That 
is fine, but I had described other use cases that have different 
requirements. I have still not seen anyone show how tools like TopBraid 
could make any sense of a given SHACL graph without properties such as 
sh:include and sh:shapesGraph. These properties are crucial for generic 
tools that are supposed to work with any given SHACL file. The 
properties would not enforce anything but only serve as hint for such 
tools, that some users MAY place in their files to help discover 
dependencies.

Holger


On 8/31/2015 11:09, Arthur Ryman wrote:
> Sorry for the delayed response due to vacation.
>
> The main OSLC use case (definition of Linked Data REST APIs) is to
> validate an RDF graph (the HTTP request or response) at a
> distinguished node wrt a named Shape. In this case the inputs to the
> SHACL processor are:
>
> 1. A pair (G, n) where G is an RDF graph (the data graph) and n is a
> node in G. (G,n) is also referred to as a pointed graph. n is also
> referred to as the root node or the focus node.
> 2. A pair (S, x) where S is a set of named shape definitions and x is
> the name of a defined shape. S is sometimes referred to as a shape
> schema.
>
> SHACL defines an RDF representation of S in which case shapes are
> identified by IRIs. However, other syntaxes for S are possible, e.g. a
> compact syntax. We define the semantics in terms of the RDF
> representation of shapes, which facilitates the use of SPARQL for
> semantics. However, the semantics of SHACL should not require the
> intermingling of the data graph and the shape graph.
>
> -- Arthur
>
>
> On Wed, Aug 5, 2015 at 10:48 AM, Holger Knublauch
> <holger@topquadrant.com> wrote:
>> On 8/5/2015 10:43, Peter F. Patel-Schneider wrote:
>>> I do not think that my statement is misleading. Yes, the only current way
>>> to
>>> access the other graphs in a dataset is via SPARQL, but if this is
>>> considered
>>> to be an important feature, then it can be put in the core/high-level
>>> language.
>>
>> Yes it is IMHO an important feature and therefore should go into the core
>> language.
>>
>>> My view is that the right place to "assemble" information together is
>>> outside
>>> of SHACL, not inside it.
>>
>> So if I want to publish a collection of instances on the web, how can I
>> communicate to other tools that I expect this file to follow the shapes from
>> a given shapes graph? People do this all the time in XML files. XML editors
>> use this information to provide auto-complete, on-the-fly syntax checking
>> etc. Just like sh:shapesGraph would do.
>>
>> Holger
>>
>>

Received on Monday, 31 August 2015 01:26:31 UTC