Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Indicate a conventional way to automatically validate data instances of application profiles #698
You can imagine a method deriving from the structures of the PROF ontology where code (a Linked Data crawler) could find a Profiles' resource with prof:role Validation (and perhaps a particular formalism of a Validation resource, such as SHACL or similar) and then it could recurse up a isProfileOf hierarchy finding all similar resources. Then, joining all those resources together, data claiming conformance could be validated against all. This would both ensure data is valid to a Profile and it's dependencies and also potentially allow Profile implementors to only have to define their extensions on the things they profile, not the full set of constraints.
In pseudo code, for
I'm not sure I quite followed this. I'm talking about the need for a conventional way to validate data against a specified application profile. If any given software validation process has to first traverse a graph in order to assemble and reconcile a collection of related validation resources, then I can't imagine that being widely implemented, or even scaling if it is. The opportunity, it seems to me, is for a documented application profile to offer a single, documented resource to facilitate automated validation of data which declares 'conformance' with that application profile.
Most probably I have misunderstood though!
@paulwalk I'm not sure you'll get exactly what you want as noone's yet able to agree on The Correct Way to validate against a profile (application profile). For instance, what constraint language is to be used, does validation need to validate against all dependency validators or not, what if dependencies use different forms of validators etc. At the moment, everyone's talking SHACL as a constraint language... except for those who prefer ShEx. And in my XML life, I use Schematron. So right there we don't have language uniformity.
Let's break this point down into sub points, just as I listed them above, but adding a few more lower-level ones:
To "Indicate a conventional way to automatically validate data instances of application profiles" PROF may need to:
For 1.: Currently Possible. The Profile just includes one or more
For 2.: Currently Possible. PROF suggests use of
For 3.: Currently Possible. PROF uses
For 4.: Not currently spelled out but perhaps able to be indicated with roles. E.g. if a validator with Role Full Constraints is used (defn: "Complete set of constraints for a profile") then it is sufficient to use this for profile validation. If only a validator with Part Constraints is available, then more info is needed.
I could imagine a new Role: "Differential Constrains" which would be this Profile's constraints, i.e. only those that this profile adds on top of those belonging to the things it is profiling. If this was available, you'd know you'd have to pull in dependency constraints to perform a complete validation.
I will suggest updates to the Roles Vocab for this.
Thanks, Nick, for taking the time to go into the detail like this.
I think we have a fundamental difference in understanding on this. In the use-case where someone wishes to validate data against some declared conformance with some metadata profile, I just don't see any advantage in the validation process being able to somehow automatically interrogate the application profile to determine which mechanisms its supports. This can be simply documented in prose - it is for the systems developer to decide which mechanism they want to use. The mechanisms themselves need formal descriptions, but that is a separate issue being taken care of by those communities.
This slightly reminds me of the huge efforts made to introduce Universal Description, Discovery, and Integration (UDDI) to web-services around the beginning of this century. Then Web2.0 came along and showed that all that was really needed was some nice clear documentation aimed at developers - what has become known as the 'Web API'.
I think Paul's interpretation is what we should be aiming for. He says "The opportunity, it seems to me, is for a documented application profile to offer a single, documented resource to facilitate automated validation of data which declares 'conformance' with that application profile." +1
@agreiner I completely agree. Notions of inheritance differ across the various technologies that people are likely to use, and it does not seem realistic to coin properties, such as
OK - so lets just focus on what is proposed again:
(and I think we have just shown that this cant be done with any universally applicable constraint language - so thats the motivator here)
Whilst we can understand a desire for a universal validation use case, thats just not realistic (that would be the UDDI equivalent). So this related Use Case is limited to finding what resources are available and canonical description of them, not a canonical form of them.
So, we can accept the comment "we don't have a conventional way to automatically validate data instances of application profiles (i.e. data which allegedly conforms to the constraints of a given application profile)" as a truism. I dont see a concrete need or proposal for change beyond stressing the scope. Adding in the "competency questions" section ( #732 ) should help keep scope in mind.
re "The discussion around inheritance and traversing a graph just to check conformance seems to be introducing barriers to use and to mixing vocabulary from multiple standards." - this is exactly what happens if you import RDFS or OWL axiomitisation. It is a barrier perhaps - but its the responsibility of the chosen set of constraints languages and how they are used that determines if navigation is necessary. The Profiles Vocabulary is agnostic about this choice. It provides the new capability of declaration of intent w.r.t. to conformance in heirarchies however, and this thread has not affected that underlying requirement or the proposed solution, so I think it can be closed as out-of-scope.
Okay, the requirement is resource discovery.
The Profiles Vocabulary implies a generalized notion of
"Declaring conformance" goes well beyond resource
Users can use appropriate technologies to test for
Or is this not about conformance of data at all?
It is confusing to talk about conformance of "a resource"
"Resource" is unhelpful as a choice of words because in
I'm seeing several types of conformance here:
A requirement for discovering profiles related to
Right, resource discovery, though I'm unclear on what
I do not see a requirement to express "declaration of