I need SPIN because my SHACL sh:constraint sh:sparql SPARQL query calls SPIN functions (some stock and some custom).
I flattened as suggested into a single turtle file. I had some test values in the schema so I piped the schema back in as the test data and got some results (yay!). Now the issue is that the results don't match what I am seeing in the TBC SHACL Validation tab. In TBC the SHACL Validation tab shows: Shape, Constraint, Message, Focus Node, Subject, Predicate, and Object. The Shape data is similar to the result in the test case, but none of the other SHACL property values are the same, most notably the Message and Focus Node values. In TBC the Focus Node (which seems to be the same as sh:subject) is bound to instances, and the Message (sh:message) value is bound to the message I defined and bound to the values my SPARQL query returns. And example of the results I am seeing from the test case is: [ a sh:ValidationResult ; sh:focusNode eddl:BlockB ; sh:message "Value does not have class sh:PropertyConstraint" ; sh:path sh:property ; sh:severity sh:Violation ; sh:sourceConstraint _:b0 ; sh:sourceConstraintComponent sh:ClassConstraintComponent ; sh:sourceShape sh:Shape ; sh:value [] ] . So now I am thinking that maybe I am using the wrong validator. Is it possible that I should be using the ResourceConstraintValidator instead of the ModelConstraintValidator? And if so, it takes a resource as the first argument unlike TBC which traverses the current graph. Jack On Monday, August 8, 2016 at 4:55:21 PM UTC-7, Jack Hodges wrote: > > We separate our schemes and vocabularies normally. Thank you for the > clarifications Holger! > > Sent from my Siemens iPhone > > On Aug 8, 2016, at 4:49 PM, Holger Knublauch <[email protected]> > wrote: > > > > On 9/08/2016 9:31, Jack Hodges wrote: > > I have looked at and run the ValidationExample from the github archive and > have looked carefully at the SHACL archive ModelConstraintValidator. These > are very helpful and I encourage anyone playing with SHACL to look at them. > This said, I have run into a bit of a problem trying to extend the example. > Here is a code fragment from a modified version of the Validation Example > in the archive: > > // Load the main data model > Model dataModel = JenaUtil.createMemoryModel(); > dataModel.read(EDDLValidation.class.getResourceAsStream("/sh/project/vocab/Data.ttl"), > > "urn:dummy", FileUtils.langTurtle); > Model schemaModel = JenaUtil.createMemoryModel(); > schemaModel.read(ValidationExample.class.getResourceAsStream("/sh/project/schema/Schema.ttl"), > > "urn:dummy", FileUtils.langTurtle); > > // Load the shapes Model (here, includes the dataModel because that has > shape definitions too) > Model shaclModel = SHACLSystemModel.getSHACLModel(); > MultiUnion unionGraph = new MultiUnion(new Graph[] { > shaclModel.getGraph(), > schemaModel.getGraph() > }); > Model shapesModel = ModelFactory.createModelForGraph(unionGraph); > > // Make sure all sh:Functions are registered > SHACLFunctions.registerFunctions(shapesModel); > // Create Dataset that contains both the main query model and the shapes > model > // (here, using a temporary URI for the shapes graph) > URI shapesGraphURI = URI.create("uri_path_to_schema_graph"); > Dataset dataset = ARQFactory.get().getDataset(dataModel); > dataset.addNamedModel(shapesGraphURI.toString(), shapesModel); > > So the questions here are as follows: > > (1) does the schemaModel graph need to be a combined graph that includes > any imports (such as separate SPIN graphs) within it or is it ok to be just > the graph that has SHACL validation functions defined within it? I suspect > that it must include the SPIN graph, and would that be done with a jena > export from TBC of the related graphs? > > > To get this out of the way, the *shapes* graph needs to include at least: > - the W3C SHACL graph itself > - the DASH namespace > > The latter includes the SPARQL queries and other info needed at runtime, > while the former should be there anyway, to get the class hierarchy correct > at runtime. I would assume the RDF systems graph should be included, too. > All this is handled by SHACLSystemModel.getSHACLModel as a convenience. In > addition to these, you certainly want to add your own shapes to that graph, > i.e. the schema model. > > I see no relation to SPIN here - so any SPIN imports should be optional > when running SHACL. But yes, the simplest thing to do would be to "flatten" > all graphs imported by TBC e.g. using the Export/Merge wizard. > > > (2) in the ValidationExample a MultiUnion graph was used because there > were some SHACL definitions in the dataset. This would generally not be the > case so this extra layer wouldn't be necessary, right? > > > The union graph is the combination of the general SHACL system graphs plus > your actual data. The whole separation between the two graphs is only > needed if you have your shapes (i.e. classes or schema) separated from > instance data. By keeping them separate, the theory is that engines need to > do less work because they don't really need the specific instances to > figure out which shape declarations exist. If you are just playing with > SHACL in a normal set up, I don't think this performance difference would > be significant. So you can basically treat shapesModel = dataModel. > > > (3) In my current case I am getting a result: @base < > http://example.org/random> . > Is this the kind of result to expect if there are no constraint violations > or have I done something wrong in the code fragment? > > > An empty results graph would mean no violations were found. It's hard to > guess whether this is correct without seeing the actual data and shapes. > > HTH > Holger > > -- > You received this message because you are subscribed to the Google Group > "TopBraid Suite Users", the topics of which include the TopBraid Suite > family of products and its base technologies such as SPARQLMotion, SPARQL > Web Pages and SPIN. > To post to this group, send email to [email protected] > --- > You received this message because you are subscribed to a topic in the > Google Groups "TopBraid Suite Users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/topbraid-users/4suqs8RewM0/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > > -- You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include the TopBraid Suite family of products and its base technologies such as SPARQLMotion, SPARQL Web Pages and SPIN. To post to this group, send email to [email protected] --- You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
