Re: Comparison with object-oriented validation, such as Java's Bean Validation

Hi Tim,

I am personally convinced that SHACL can play a big role in validating 
OO models. In fact my very first draft of SHACL was called Linked Data 
Object Model. And yes my (now "ancient") PhD work was about JavaBeans 
too (that was before Java had annotations). We have furthermore recently 
added a JSON-LD profile for SHACL to make it easier to use for this 
community, too. A big plus of SHACL over technologies like JSON Schema 
is that SHACL is natively working on graphs, not just trees.

So yes, we are very much aware of these use cases. I believe what you 
are describing would be a very nice follow-up project, e.g. in a W3C 
Community Group.

(Looking at the Java source code below I would be hesitant to embed 
Turtle snippets into Java, it just doesn't fit. However, the Java file 
could point at the namespace of a SHACL graph and then reference 
specific shapes by their URI).

Since we are nearing our deadline for comments, I would like to make 
sure that we have not missed any actionable work items. We are also 
supposed to "close" any open email threads, so please let us know if you 
think there is more required to answer your input at this point or if we 
can "close" this thread. (Actionable comments should be turned into 
GitHub issues).

Thanks,
Holger


On 17/03/2017 1:29, Timothy Armstrong wrote:
> Hi Data Shapes community,
>
> I'm very glad you're working on RDF validation standards, which has 
> always been something that would really benefit the Semantic Web.  I 
> wish I had gotten involved in the conversation before now.
>
> I read the February 2nd SHACL draft and compared it with Java's Bean 
> Validation standards [1], which is apparently the most popular 
> approach to validating Java data.  I've been thinking about aspects of 
> Bean Validation that could be incorporated into SHACL, and aspects of 
> SHACL that could be incorporated into Bean Validation.  They posted on 
> February 2nd the first draft of a 2.0.0.Alpha1 revision of the Bean 
> Validation specification, and they are inviting public comment.
>
> I know it's hard to incorporate new ideas into SHACL at this point.  
> Bean Validation has a mechanism for users to specify the order in 
> which constraint checks are executed, such as to run inexpensive 
> checks before expensive checks.  You would probably consider it 
> inessential to add such a mechanism to the SHACL standards, but I 
> thought I would mention it.  Maybe it would be useful for SHACL 
> implementations.
>
> The most interesting part of the comparison to me, though, is that 
> SHACL can be used mainly directly to validate object-oriented data.  
> SHACL of course works as it is with JSON-LD, but I have in mind to use 
> it with all sorts of object-oriented data.  SHACL has some features 
> that would be valuable additions to Bean Validation, either as part of 
> the Bean Validation standard, or as a separate piece of software.  I 
> expect the Bean Validation developers would welcome proposals for 
> incorporating aspects of SHACL.
>
> I'm accustomed to working with an interpretation of object-oriented 
> classes as unary predicates and as OWL classes, of object-oriented 
> attributes as binary predicates and as OWL properties, and so of a set 
> of object-oriented data as a set of RDF triples.  Object-oriented data 
> form a graph; objects have attributes with values of literals and 
> other objects: nodes, edges, and other nodes.  I have a mechanism for 
> annotating Java classes and attributes with IRI's, metadata, and 
> semantics so that they become OWL classes and properties, similarly to 
> how JSON-LD marks up JSON data.
>
> I like the whole idea in SHACL of writing shapes to specify the 
> structure of the data graph, which is something Bean Validation could 
> include but presently does not.  Bean Validation users writing custom 
> constraints mainly have to write the logic of the constraints as Java 
> code in an isValid() method.  We might say that SHACL provides a more 
> declarative approach to writing constraints.
>
> Consider a Person Java class with attributes for some of the RDF 
> properties in the SHACL document -- fullName, firstName, lastName, 
> ssn, parent, etc. -- with ex:XoneConstraintExampleShape taken directly 
> from the document:
>
>
> @hasShape(
> "@prefix ex: <http://example.com/ns#> . " +
> "@prefix sh: <http://www.w3.org/ns/shacl#> . " +
> "ex:XoneConstraintExampleShape " +
> "    a sh:NodeShape ; " +
> "    sh:targetClass ex:Person ; " +
> "    sh:xone ( " +
> "    [ " +
> "        sh:property [ " +
> "            sh:path ex:fullName ; " +
> "            sh:minCount 1 ; " +
> "        ] " +
> "    ] " +
> "    [ " +
> "        sh:property [ " +
> "            sh:path ex:firstName ; " +
> "            sh:minCount 1 ; " +
> "        ] ; " +
> "        sh:property [ " +
> "            sh:path ex:lastName ; " +
> "            sh:minCount 1 ; " +
> "        ] " +
> "    ] " +
> ") .")
> @hasIRI("http://example.com/ns#Person")
> public class Person
> {
>     @hasIRI("http://example.com/ns#fullName")
>     private String fullName;
>
>     @hasIRI("http://example.com/ns#firstName")
>     private String firstName;
>
>     @hasIRI("http://example.com/ns#lastName")
>     private String lastName;
>
>     @pattern("^\\d{3}-\\d{2}-\\d{4}$")  // sh:pattern
>     @hasIRI("http://example.com/ns#ssn")
>     private String ssn;
>
>     @maxCount(2)  // sh:maxCount
>     @hasIRI("http://example.com/ns#parent")
>     private Collection<Person> parent;
>
>     // ...
>
> }
>
>
> The SHACL constraints would work with the Java data here exactly as 
> they do with RDF.  Some of the SHACL constructs would make sense to 
> place as annotations directly on attributes, as sh:pattern and 
> sh:maxCount here (though Bean Validation already has @Pattern and 
> @Size for those two purposes).  Bean Validation doesn't have anything 
> like sh:xone, which I show here because I think it would be very 
> useful in Java.  SPARQL property paths would be useful to inspect the 
> attributes of nested objects. Shapes could also validate arguments to 
> methods.
>
> I wrote some software for incorporating the OWL reasoning and SPARQL 
> into Java [2].  My suggestion for using SHACL to validate Java data is 
> a direct extension of that approach.  I have a bit of code working to 
> validate Java data with the TopBraid SHACL API; I could post the code 
> on GitHub if you're interested.
>
> I wanted to post here while you are still open to comments because I 
> thought you may not have considered this approach of applying SHACL 
> more broadly to object-oriented data.  I also thought there's a chance 
> you're not aware that Bean Validation is currently in an open 
> development phase, which might somehow be useful to you, as it's 
> closely related to SHACL.
>
> Regards,
> Tim Armstrong
>
> [1] http://beanvalidation.org/
> [2] http://semanticoop.sourceforge.net/
>
>
>

Received on Friday, 17 March 2017 01:05:20 UTC