As someone who has practiced in information technology standards groups and actively worked on data schema standards to facilitate data sharing and even legally valid business transactions (https://www.oasis-open.org/committees/download.php/31222/ENML-1.0-Specification.pdf), my experience indicates it is important that you do the following:

1) Create a small workgroup of the right stakeholders who are committed to the process and results;

2) Pick a schema definition language - JSON or XML - to create the standard (JSON is the flavor of the day, but it is possible to do both with the right commitment);

3) Get people trained on the methodology and grammar for creating the schema;

4) Build the right semantic model up to a level of detail that is feasible for implementation within one year - if you go deeper than that the people who need to get things done in the field will move on while the workgroup will still be arguing details;

5) Build the schema; and

6) Build at least reference tools and applications in at least 2 different programming languages that show the model and schema working.

Without this process, it will be easy to miss the forest by getting lost in the trees (apologies for that).

Arshad

I don't know that it would be possible to create one scheme across all fields and collection tools. I'm involved in a project trying to define shared data standards with 10 private companies in one sector and that's a multi-year discussion. KDEs for seafood traceability (not even a full schema) took 5 years. If by standards you mean general agreements in principles, then maybe working with the ODI would be a good approach (see the work they did on engineering). if you want to get to schemas, maybe check with Matt Jones at NCEAS, bc data science for ecology is his career's work.

Hi skatewing,

I'm not a domain expert like most people in this forum, but I have created XML schemas using object oriented (OO) principles in the past; the same capability exists with JSON schemas.

The important thing is to create a heirarchy of schemas, starting with a generalized schema definition that applies to all participants at the upper layer, and inherit that schema as one starts diving deeper. This permits specialized schemas at lower layers that meets the needs of smaller groups, but as one moves up the schema hierarchy, one finds common parent objects that can be shared with other groups.

If it is impossible to create it in a hierarchy for all group participants, it is possible to start with a smaller general schema that meets everyone's needs and then each specialized group can create independent hierarchies, which can then be linked as necessary (https://json-schema.org/learn/getting-started-step-by-step.html#references)

This capability of inheriting parent schemas, and linking to external schemas, allows simultaneous - yet separate - development by many groups without having to involve everyone all the time. You do need to bring together many people for a short while for the more general parts of the schema at higher levels; but once defined, it can segment out to smaller groups as specialized schema branches/hierarchies are defined.

Arshad