Workshop 4 - Standards Working Group

[chporter]

Notes from 2021-06-02 workshop

[chporter]

"Standards" may be too strong a term. Consider "practices" or "guidelines".

[chporter]

Guidelines - might be more palatable, helpful. Intended to save modelers time if they are adopted.
Standards - might be too intimidating.

[chporter]

Other forms of auxiliary documents: white papers, recommendations.

Guidelines could transform into standards as they become adopted.

• Staging elements that have been adopted - candidate standards.
• evidence of implementation.

[chporter]

"Standards" have gravitas. People will pay attention.

[chporter]

Indicators --> Metrics --> Standards

[chporter]

Guidelines are more fluid, changing often, improving constantly
Standards - "gold standard" marking highest aspiration.

Guidelines might be provided for particular scenarios for implementing standards.

[chporter]

OMF as aggregator of standards. Look at other organizations that already promote standards.
e.g., WC3

[chporter]

Huge amount of effort to start from scratch.

[chporter]

RDA working groups -
required to name at least two adopters initially
get endorsement to target groups.

[chporter]

Standards Workflow:
Target modeling groups for comments - instead of "Modeling Community".. People don't typically respond to general requests for comments.

[chporter]

These target groups become invested and can spread adoption.

[chporter]

Types of models:

• simple (long tail) models from individual labs
• complex, multi-institution, long term
• statistical models
• ...

OMF should be inclusive to any type of models. Guidelines need to be generic enough for all.

Do we need a separate set of guidelines for smaller models? How to distinguish? Number of users.
Some of guidelines may not be applicable to all models.
Documentation - most guidelines are pertinent to all models (large and small).
Accessibility - OK for all models.
Reusability - Probably same guidelines for all models to strive for.
Interoperability - much harder. Not all models can / should be made interoperable.

[qincz]

Is there any ontology of model, available for this?

[qincz]

I think in current interoperability standard, only parameter and variable ontology were mentioned clearly.

[chporter]

From Josh Greenberg:
The RDA example I described: https://rd-alliance.org/recommendations-and-outputs/all-recommendations-and-outputs

[chporter]

Time limit on review process:
Comments / review time easier
Synthesis and revision time (harder)

Categories of revisions: trivial, minor, major - may have different timelines.

[chporter]

Standards working group - maintainers of project
Targeting communities for revisions and pull requests
Use native tooling of software development - for versioning and revisions

[chporter]

who gets commit access?

[chporter]

parallels with publishing - consider publishing standards / guidelines in journal.

Journal of Open Modeling Software - clone the infrastructure for a new journal.
Need community of reviewers, editors

[chporter]

could include open review by community (e.g., Copernicus NESS) as well formal reviewers.

[chporter]

Maybe better to keep it simple rather than have a huge infrastructure. Standards will be fairly static.

[chporter]

Starting a standard can be contentious. Good for transparency.

[chporter]

Maybe better to have many small standards that people can choose from rather than one large document.

[kettner]

Core principles of open standards: https://open-stand.org/infographic-the-5-core-principles-of-openstand/

[chporter]

On flow diagram
Where does proposed standard originate? could come from modeling community.
"Comments" box should also include "Suggestions" perhaps.
The modeling community should be able to suggest changes.

[chporter]

Executive committee needs to work with modeling community at all times.