DC-SRAP Working Group and the Usage Board

[tombaker]

The process DCMI-endorsed application profiles: review and approval processes was developed in 2020-2021 by Juha, Paul and me, with review and input from members of the the Governing Board and Usage Board, in order to describe, among other things, the relationship between this working group (and similar working groups to come) and the Usage Board.

As of now (March 2022), this working group is at step 6 in the process - ie, the working group is meeting, discussing, and resolving issues. The following steps are:

7. When the draft is deemed mature, it will be posted for public comment for at least one month. All substantive issues raised will be publicly addressed and resolved. The working group may invite the wider community to indicate their interest in the draft profile as evidence of community demand.
8. Once public review is complete, if a required property is not found in existing namespaces, it may be proposed by the Working Group to the Usage Board for incorporation into DCMI-MT.
9. Once a draft profile has passed public comment and is considered by the working group to be mature enough for publication, it will be submitted by the working group to the Usage Board for final review.
10. The Usage Board will review any proposed properties and communicate their decisions to the profile working group. The Usage Board may ask the working group to revise and resubmit a proposed property.
11. Once a draft profile is considered to be ready, with all properties defined in namespaces (including DCMI-MT), the working group submits the entire proposal to the Usage Board for final approval.
12. The Usage Board reviews the draft profile with regard to completeness and clarity of documentation. The Usage Board may ask the working group to revise and resubmit or, if no issues remain to be addressed, it approves its publication as a "DCMI-endorsed" application profile.
13. Once endorsed, the profile will be published on the DCMI website and any terms approved by the Usage Board will simultaneously be published in a new version of DCMI Metadata Terms.

[tombaker]

Although the agreed process document does not require Usage Board review before the public comment period, I suggested that the working group already share a draft with the Usage Board for informal review when the group feels that it is mature enough to share.

What I picture is a document describing the (proposed) properties and classes in the "style", as it were, of DCMI Metadata Terms, ie:

• Short name to be used for the URI (ie, dateAvailableAsDraft)
• Label in English (ie, "Date Available as Draft")
• Definition (!)
• Type of term (property, class or, conceivably, datatype)
• Usage comment
• Domain or range (if applicable)

I would expect this document to be in minimally formatted Markdown (and not DOCX or PDF) and posted on this repository (and not, say, on Google Docs). The exact format is really not important as long as the document is clear.

I would expect a Chair of the DC-SRAP working group to ask for review in the form of a note posted to dc-usage@jiscmail.ac.uk explaining:

• A sentence or two about the working group, with links to the repo, mailing list, and issue tracker.
• What sort of review is being requested. In the case I picture, this would be: "informal review prior to the public comment period", citing the process document as above.
• A brief description of the application profile, ie what requirements it meets, and drawing attention to any unusual or innovative modeling decisions taken (eg, re: "affiliation").
• A deadline by which you would like to have comments.

I would expect the Usage Board to provide an (informal) review of the proposed properties and classes with an eye to how well they make sense in themselves - ie, independently of the application profile. The proposed properties and classes will have to make sense to people who may know nothing at all about the SRAP profile in particular; they must be defined, and applicable, in the general.

[tombaker]

Note that the process document refers to DCMI wanting to strike "a balance between a desire to keep the DCMI-MT vocabulary small and generic, and a need to provide URIs in the DCMI-MT namespace for properties needed in application profiles developed by DCMI working groups". If granular detail is required in an particular area (eg, dates of submission, acceptance, etc), the Chair could call attention to this in the cover letter.

[tombaker]

One simple way to do this would be to create a top-level folder, /profile/, and start by converting the original Google draft of 2021 into Markdown and posting it there.

There could be a second-level folder /terms/, for any term proposals. I would suggest putting each term into a separate file, eg /terms/dateAvailableAsDraft.md, so we can easily cite them from Github issues. Those proposals can be edited in place as discussions proceed and definitions get added.

The 2021 draft of the profile should probably be posted as a permanent part of the record and not be touched. Alongside this, a version could be created that the WG can simply edit in place.