Discussion: The future of this validation method

[ptsefton]

This issue is for discussing the future of this library.

Things we want to keep:

• Ability to programatically validate RO-Crates to a profile (we have this library, but also now some validation using ro-crate-metadata-profiles which takes care of basic structural relationships between Classes and Properties). This is currently used batch corpus tools. Crate-O does simpler validation using RO-Crate Editor Profiles
• Automate producing parts of a human-readable profile (tables of required and optional properties etc)
• Validation of property values (things that can be done with Regex like validating URIs)
• Complex constraints like the root data set must have a type RepositoryCollection or RepositoryObject but not both.
• Validating inheritance of properites from Collection or Object to linked files (not sure if this is needed really)

Questions:

• Can we keep the current functionality by merging some of the RULES in this library into ro-crate editor profiles?
• Can we embed JSON-Schema fragments for some validation tasks in RO-Crate Editor Profiles? (Similar to bioschemas profiles)
• As a fallback, if the above does not cover all the validation we need, could we call out to external validation functions from an RO-Crate-Editor profile (import a script as specified in the profile, this might be necessary for complex validation like tracking inheritance of properties across a graph or checking that values match things available in lookup services)

For discussion @alvinsw @moisbo @rosanna-smith @mraadgev @alex-ip