Assess and include relevant OBPS fields in MIOP

[kpitz]

Evaluate OBPS metadata fields and include as needed in MIOP.

[raissameyer]

The OBPS submission guide notes the following:

Language: Enter the language of the full text deposit, If the language does not appear in the list below, please enter 'Other'. If the content does not really have a language (for example, if it is software, a dataset or an image) please enter 'N/A'. English || Chinese || French || German || Italian || Japanese || Spanish || Other || N/A ||

Note However, in practice I see "en", which would suggest (rightfully so) to follow the ISO 639-1 two letter language code

---

Methodology type: Enter the type of methodological document you are submitting. Please enter all that apply. Separate entries with a semicolon (;)

Note They suggest the following:

---

Adoption level: Please indicate how broadly the uploaded methodology is used and/or adopted; please select all that apply. Novel (no adoption outside originators) Validated (tested by third parties) Organisational Multi-organisational National International N/A

---

Endorsement (author declared)

Please enter if your submission (in its entirety) has been endorsed by an organisation or community as one or more of the following: De jure standard: A methodology that an official authority has legally declared as a reference or authoritative model. De facto standard: A methodology that has become a reference or authoritative model through wide adoption and common use in at least one community of practitioners. Good practice: A methodology that has repeatedly produced reliable, fit-for-purpose results with regard to its stated objectives. Recommended practice: A methodology that has been recommended for use by an authority, organisation, community, or other group. Best practice: A methodology that has repeatedly reproduced superior results relative to other methodologies with the same objective and which has been adopted and employed by multiple organisations.

---

Endorsement (external): Please indicate whether this submission (in its entirety) has been endorsed by an organisation or community. Please name the organisation or community that performed the endorsement above.

---

Author Last, First Name(s) Separate multiple entries with a semicolon (;) e.g.: Smith, Joseph; Jones, H.; (enter the name/s as it appears in the document in the correct order)

---

Author ORCID(S) eg. 0000-0002-4366-3088 Separate multiple entries with a semicolon (;) Visit https://orcid.org/ to register The order of these entries should correspond to that of the names above

---

Editor Last, First Name(s) Where there is no personal author list the editor/s. Separate multiple entries with a semicolon (;) (enter the name/s as it appears in the document in the correct order) eg: Buttigieg, Pier Luigi; Simpson, Pauline;

---

Editor ORCID(s) e.g.: 0000-0002-4366-3088 The order of these entries should correspond to that of the names above. Separate multiple entries with a semicolon (;)

---

Corporate Author Where there is no personal author or editor enter the organization, project or team name responsible for creating the best practice, eg. CleanSea Project

---

Date of Issue (yyyy-mm-dd) ** e.g. 2018-05-21

---

Recommended Next Content Review Date (yyyy-mm- dd) Please indicate the date which you believe the document should be revised and updated

---

...

Stopping here, as we will go through the OBPS template in the meeting. We will note any relevant fields below.

[raissameyer]

Going through the OBPS template, noting decisions made in 2022-07-20 meeting below:

Language:

• already included

Methodology type:

• BeBOP is really only about the protocol, based on BeBOP's scope we would expect all to be methods so we do not need to include this term
• additionally, we have the audience term to capture some of this

Adoption level:

• useful, e.g. to differentiate a NOAA protocol from one that is only used by one laboratory and should be included

Endorsement (author declared)

• this can be applied, is important, and should be included
  • should add a term on the endorser (split this term in the "endorsement level", and "endorser")
  • need to check if we can include definitions to make sure the terms are used accurately
  • if you claim a "BP", be sure to include an appendix showing how you tested it

Endorsement (external)

• field for e.g. GOOS to declare that some protocol is a "best practice", etc.
  • This is an internal OBPS process, and cannot be applied for MIOP

To be continued in the next meeting

[raissameyer]

Going through the OBPS template, noting decisions made in 2022-08-03 meeting below:

Author Last, First Name(s) this is pretty much mapped to the MIOP term creator.

Author ORCID(s)

• add for the MIOP creator field
• make this more generic, please enter your de-referenceable, web-accessible identifier (e.g. ORCID)

Editor Last, First Name(s)

• in the OBPS intended for when a project releases all of its methods and there is an editorial team
• decided to leave this out for now as MIOP is intended to be minimal

Editor ORCID(s)

• leave out for now (see above)

Corporate Author

• as the OBPS Author term, this can be captured in DC:creator
  • this can be human individuals or organisations

Date of Issue (yyyy-mm-dd)

• already captured in MIOP

Recommended Next Content Review Date

• not needed (as this is not minimal)

English-language document title

• the OBPS requires at least the abstract and the title to have an English translation, as we do not have that as a requirement, we don't need this
• however, we should add a MIOP term for title
  • check DC for a term like this
  • this will facilitate search across titles

Alternative or Non-English document title

• do not add, but add term for title (see above)

Place of Publication

• should be added, in terms of library science this is essential, e.g. when things are re-published in a different country some information would be left out. This is part of core DublinCore

Publisher Name(s)

• should be added, there may also be a DC term for this

Pages or Extent

• not needed, especially if these documents are created in Markdown, we don't have page number

Series and or Document Number(s)

• don't think we need this, more for government agencies or people publishing volumes of books. Not needed now.

External Identifiers

• in BeBOP GH would publish the markdown, then in Zenodo that would get a DOI 37
• add, and check DC for an appropriate term

to be continued in the next meeting ...

[NickJeff13]

I think External Identifiers would correspond to 'identifier' under DC, which can include DOIs, URIs, and ISBN

[raissameyer]

I think External Identifiers would correspond to 'identifier' under DC, which can include DOIs, URIs, and ISBN

@NickJeff13, agreed.

This term exists in Dublin Core both in the /terms/ namespace and the /elements/1.1/ namespace. The guidance provided by the DC team ("While the /elements/1.1/ namespace will be supported indefinitely, DCMI gently encourages use of the /terms/ namespace.") suggests to use the term in the /terms/ namespace: http://purl.org/dc/terms/identifier

Below I have further added suggestions for the other OBPS metadata fields that we wanted to consult DC for:

• OBPS Author Last, First Name(s) & OBPS Author ORCID(s) & Corporate Author - DC:creator http://purl.org/dc/terms/creator
• OBPS English-language document title - DC:title http://purl.org/dc/terms/title
• OBPS Publisher Name(s) - DC:publisher http://purl.org/dc/terms/publisher

We would link to the DC terms as we have done for MIOP:language (see here)

[raissameyer]

Official location of document

• we do not understand this field -> don't add

Contact person - Last, First names

• may change
• similar to corresponding author in papers, may not be an author though
• ask for a persistent identifier instead
• field nameContact valid entries would include a PID that has an email information associated with it or the email itself
• could be a support address to ask for help on the protocol
• check DC for a term like this

Contact person - Email

• captured in the field above

Abstract/Summary

• there is DC term for abstract
• it may be a bit more than minimal, holding off on it for now
• may help text mining

Refereed Status

• not really minimal and not needed here

Maturity Level

• should be added as we expect documents of different maturity levels
• notes TRLs (e.g. defined by FOO, NASA, ...) we'd have to choose one system and specify it (the interpretation of TRLs for protocols, have those in our GH repo, and link to them in the MIOP specs) Action
• @jodievandekamp notes that IMOS uses the FOO TRLs, https://imos.org.au/facilities/newtechnologyproving/#:~:text=Assessment%20of%20the%20technical%20readiness%20level%20%28TRL%29%20of,below.%20Evidence%20of%20user%20demand%20for%20the%20observations%2Fdata

Spatial Coverage

• we may have something like that already -> geographic location
  • need to update the term to include which resource should be used (@pbuttigieg notes that GAZ is not being maintained, OBPS suggests using https://www.nodc.noaa.gov/worlddatacenter/regions.ht ml)
  • Action Update term guidance to say "please enter the region in which this protocol has been developed or tested"
  • May not be as relevant in the lab but @Neil notes that this can still be interesting to think about resources in different parts of the world
  • Any entry that would come in under MIOP should be a valid entry for the DC:coverage term, our guidance would just be a bit narrower
• DC has the term coverage which could be applied to temporal or spatial coverage

Note this discussion has shown that the semantics of the other MIxS terms that we have been reusing in MIOP (four in total) are also different in a way that we can actually not re-use their IRIs. We have to update the MIOP term list accordingly.

Sustainable Development Goals, Targets, and Indicators

• for the purpose of OBON this is minimal, for the GSC not
• this would be a first case for an OBON package, in which this term would fall

[raissameyer]

Note linked to the SDG field: For OBON, a field on which Decade Challenge the given protocol pertains to, should also be added to an OBON extension for MIOP

[raissameyer]

Continued during 2022-12-07 BeBOP meeting

Essential Ocean Variables (EOV)

• not minimal for GSC, EOVs could be for OBON

Essential Biodiversity Variables (EBV)

• not minimal for GSC, EOVs could be for Omic BON

Essential Climate Variables (ECV)

• not minimal for GSC

Other Variables

• not minimal for GSC

Sensors

• overlaps with "materials provided" field
• if we wanted to map: note that this is "materials provided" is a broad match to that
• can review as the need changes

Other Keywords

• not minimal

citation

• not minimal,

license

• important, check Dublin Core for term
• needed to be FAIR, obligatory
• in text, note that there are options such as share alike