Re: ISSUE-3 how to specify the shape information and the data information

Why do we need to worry about start node and start shape in this spec? 
Isn't this application-specific? A service just returns data for many 
possible use cases, often including multiple resources. In Arthur's case 
it seems he already has all info that he needs (the URI of the main 
resource), and could use whatever metadata he wants to invoke the 
constraint checking (e.g. the validateNodeAgainstShape operation from 
the draft). And we already have the property sh:nodeShape that links a 
resource with its shape.

I do however very much agree with the need of an RDF property that links 
a graph with a set of shapes that apply, by default. I am currently 
using sh:shapesGraph for that purpose (not mentioned in the draft yet). 
The presence of such triple is very helpful for generic editing tools 
that are supposed to edit any data from the web, or any file that is 
given to it. We cannot always rely on things like HTTP headers here. If 
someone starts constraint violation with Peter's first scenario 
(supplying all info) then the values of sh:shapesGraph would be ignored.

And once we are there, I'd also like to see a similar property 
sh:include (or sh:includedGraph) that can be used similarly to 
owl:imports, but for use within SHACL. If present, this would expand the 
default graph of the query dataset by its transitive includes closure. 
Again, very important for editing tools - how else could we figure out 
which other files to load before we can display a class tree? 
Following-your-node is not a realistic option.

Thanks (and apologies I missed the discussion about this last night).
Holger


On 5/22/2015 4:40, Peter F. Patel-Schneider wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> I added a section to
> https://www.w3.org/2014/data-shapes/wiki/ISSUE-3:_Graph_Shape_Association
> providing two ways to invoke a SHACL engine.
>
> In the first way there are two arguments, one for the shapes and one for the
> data.  This is the no-linking method and is the most basic invoking mechanism.
>
> In the other way there is one argument.  This argument can either contain
> the data or point to some other place to get the data.  This argument can
> either contain all the shape stuff or point to a place where there is more
> shape stuff.
>
>
> Under this proposal a service could return an RDF graph that contains
> something like this:
>    The start node is X
>    The start shape is S
>    Look at <https:...> for the shape definitions and other SHACL stuff
>    ... data ... data .. data
> To verify this claim a SHACL engine would run the shapes starting at the
> start node and the start shape against all the data in this graph.
>
>
> A service could also return a small RDF graph that contains something like thi
> s:
>    Look at <https:...> for the scoped shapes
>    Look at <http:...> for the data
> To verify this claim a SHACL engine would check that the data satisfies the
> scoped shapes.
>
> Note that in the first service example that whatever encoding is used to
> specify the start node, start shape, and pointer to the other SHACL stuff
> ends up as part of the data that is being checked whereas in the second
> service example no SHACL-related informmation need show up in the data being
> checked.
>
>
> peter
>
>
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJVXiaMAAoJECjN6+QThfjzyKkH/2bi5du4Xls5be9aNSAw+ZLP
> ZxlJBpYuWT7S9PajeB2P63Uqh03CGMeWsViOCNjfjAZldDmGGyIu+UJsQDmvAf8w
> SCkQPZFTwOfDnphlSGkHz1tgJSmpo9gboXTJoc39sJD1BwOSHC9naHSZGCLCvVWC
> vv7cffvnsmarJq7evknY4IiGgeYFdlToCyy1ZjtYE9nDkcYxRKJ7Fh6rABdsMZvO
> /QOFRROArbIN6yB8zU6/P6/Ov9Yvg0ruGbpNC/e49VJzWRWETvr5IEu/n1IIXHsR
> Y+Z5P2wKXW6z+CfrQJ5KHTh+Lw2Tfx8kbKZ2Yyr0HMvfsDDc8XXqVgqkbt/y8gg=
> =Spfu
> -----END PGP SIGNATURE-----
>

Received on Thursday, 21 May 2015 23:46:41 UTC