Proposal for Governing science-on-schema.org as the ESIP Schema.org Cluster

[ashepherd]

ESIPFed/science-on-schema.org

This repository is for guidance documents and science domain agnostic extensions to be promoted up to schema.org.

Github App Weekly Digest bot will keep the ESIP Cluster mailing list up-to-date. This gives lurkers an opportunity to grok what's happening without having to jump into Github.

Using Github Issue queue

• create a templates for:
  • Guidance document changes
  • Science-related, Domain agnostic extensions to propose up to core schema.org

Guidance Document Template

• What fields/questions do we need to ask?

Vocabulary Extension Template

• What is the use case? What is Competency Question that is answered?

Governance Workflow for Github Issues

• ongoing community comments in the Issue
• a fork or branch is created for the proposed work,
• when consensus arrived,
• an Architectural Decision Record (ADR) is generated to summarize the decision,
• a pull request is created,
• reviewed by community
• pushed after review

Git branch and release workflow

• The master branch of the GitHub repository always reflects the most current release
• A development branch is used for development work to extend the guidelines for each of the ADRs
  • Each ADR is associated with a pull request against the development branch, and the PR should reference the issue number for the ADR in the template
  • Any PRs should be merged into the development branch when they have been approved as a good implementation of the ADR
• The development branch is merged into master and tagged to create a new release when it has been approved for release
  • Alternatively, we could create a release candidate branch for review before merging to master, but this is likely more complicated than we need (e.g, rc-1.1.0)
• Any highly experimental work that needs to be shared but is not ready for release can be handled either as a pull request against the development branch, or as a separate feature_* branch that is appropriately named for the feature (e.g., feature_dcat_alignment)

Components of a Good Branch/Fork

Guidance Documents

• JSON-LD snippets
• Prose describing/explaining the guidance
• Diagram of related classes and properties

Vocabulary Extension

• a Diagram of the proposed extension,
• a Turtle file (JSON-LD??),
• a SHACL shape is recommended to demonstrate a successful design,

This issue obsoletes issue #7 with the formation of the ESIP Schema.org Cluster

[ashepherd]

ESIPFed/geoschemas.org

• github.com/geoschemas-org
• a place for geoscience-specific schema.org extensions
• sibling to bioschemas.org (Health and Life Sciences)

REASONING: Keep science domain agnostic work at science-on-schema.org but support the geosciences in a place that doesn't need to bother life sciences and others who may join the science-on-schema.org effort.

• move under the ESIPFed Github organization akin to science-on-schema.org
• hosts vocabulary extensions and is served as content negotiated web resources
  • JSON-LD, HTML
  • HTML would look similar to bioschemas and schema.org in format with a different color to differentiate ourselves.

[ashepherd]

Development model for ESIPFed Schema.org repos

• use Github Release mechanism
  • Release notes linked to issues in the respective Issue queue

Extensions

• follow schema.org modeling conventions (e.g. schema:domainIncludes, schema:rangeIncludes)
• investigate alignment module for getting stronger statements in OWL (re: SOSA & SSN)
• weekly digest pushed to ESIP schema.org cluster mailing list for broader exposure (Dan Brickley & other lurkers)
• website running on ESIP infrastructure, lightweight - zazuko triffid + Jena Fuseki to visualize the schemas & handle content negotiation of URIs
• pages look like schema.org (with LAF consistent with bioschemas & schema.org)
• generate website from Turtle (SPARQL queries, etc.)

[mbjones]

I’d like to reincorporate the git branch management from issue #7 into this discussion. In particular, we need to explicitly address how we manage releases on git branches. I propose that the master branch, which is what most people will be viewing online, should reflect the most current release. Which means that we would need to manage new work in a development branch. This helps people follow the current stable guidelines, at the expense of making the development process more complicated for contributors (they would need to merge pull requests into the development branch). So, I’d like to modify the governance above to add the following section on branch management.

Branch and release management

• The master branch of the GitHub repository always reflects the most current release
• A development branch is used for development work to extend the guidelines
  • Any PRs should be merged into the development branch when they have been approved
• The development branch is merged into master and tagged to create a new release when it has been approved as described in this document
  • Alternatively, we could create a release candidate branch for review before merging to master, but this is likely more complicated than we need (e.g, rc-1.1.0)
• Any highly experimental work that needs to be shared but is not ready for release can be handled either as a pull request against the development branch, or as a separate feature_* branch that is appropriately named for the feature (e.g., feature_dcat_alignment)

[ashepherd]

See: https://datasift.github.io/gitflow/GitFlowForGitHub.html

[mbjones]

Renamed decision files to follow the naming convention, and added issue links to all of them. I think this issue and associate PR #73 are ready for review and merge.

[mbjones]

PR #73 was merged to develop and is ready for release. I updated the ADR to reflect the Accepted status. Please create a new issue for any additional details regarding changes to the governance and release process.