- From: Arthur Ryman <arthur.ryman@gmail.com>
- Date: Thu, 29 Oct 2015 13:21:02 -0400
- To: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Cc: Holger Knublauch <holger@topquadrant.com>, public-data-shapes-wg <public-data-shapes-wg@w3.org>
I generally agree with this proposal. I am in favour of using sh:scopeNode as the semantically inverse property of sh:nodeShape. The way this would work in the Linked Data use case for GET/PUT/POST is that the application would do some preprocessing. Let the standard shape be S and let the HTTP payload be the data graph D. The application (client or server) would split D into D' and X where X contains the sh:scopeNode triple (or triples). Let S' be the graph merge of S and X. The application calls a SHACL processor to validated the data graph D' using the shapes graph S'. -- Arthur On Thu, Oct 15, 2015 at 6:59 AM, Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de> wrote: > > > On Thu, Oct 15, 2015 at 2:13 AM, Holger Knublauch <holger@topquadrant.com> > wrote: >> >> On 10/14/2015 17:47, Dimitris Kontokostas wrote: >> >> I propose to resolve issue 61 by stating that >> >> Individual resources can be directly associated with a shape by linking >> from the shape to the resource using the property sh:shapeNode e.g. >> ex:myShape sh:shapeNode ex:myInstance >> >> when ever such a triple exists, ex:myInstance should comply with the >> definition ex:myShape. >> >> This approach excludes validation data from direct resource's data in >> cases of data merging and does not interfere with closed shapes where the >> current sh:nodeShape property needs to be manually excluded. >> >> As an alternative for people who want the reverse relation (resource to >> shape) is to use the existing sh:nodeShape property with the property >> linking to an intermediate resource that has two properties, a shape and a >> context e.g. >> >> ex:myInstance sh:nodeShape [ >> sh:shape ex:myShape >> sh:context ex:MyGraph >> ] >> >> >> I believe this reification takes it a bit too far (we could in theory >> apply this to every SHACL triple) and this info is already available via the >> quads of the named graphs. >> >> My proposal is: Resolve ISSUE-61 by replacing sh:nodeShape with >> sh:scopeNode which points from a sh:Shape to a node. Like sh:scope and >> sh:scopeClass, the sh:scopeNode triples are expected to be in the shapes >> graph. > > > Holger's simplification is perfectly fine by me > > > -- > Dimitris Kontokostas > Department of Computer Science, University of Leipzig & DBpedia Association > Events: http://wiki.dbpedia.org/meetings/California2015 (Nov 5th) > Projects: http://dbpedia.org, http://rdfunit.aksw.org, > http://http://aligned-project.eu > Homepage:http://aksw.org/DimitrisKontokostas > Research Group: http://aksw.org >
Received on Thursday, 29 October 2015 17:21:29 UTC