- From: Timothy Armstrong <t.armstrong444@gmail.com>
- Date: Thu, 16 Mar 2017 11:29:09 -0400
- To: public-rdf-shapes@w3.org
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 Thursday, 16 March 2017 15:45:05 UTC