2023 03 02 Board Meeting Notes - mets/METS-board GitHub Wiki

iPRES

Deadline is coming up, we need to review to see if we have what we need. Likely attendees at iPRES: * Juha * Karin * Aaron * Tobias, Inge would like to

Karin will submit it.

Should we submit anything if we have not received any feedback on METS 2?

Changes in the proposal are primarily to indicate that METS 2 will be covered and transition from METS 1 to METS 2 are there.

Should be reviewed by someone with English as a first language.

Do we want to maintain agenda point of PREMIS in METS? Instead of listing just PREMIS, will suggest it will show examples of embedding other XML metadata in METS 2, including PREMIS, EAD, etc. PREMIS is important, but we are presenting a METS tutorial rather than PREMIS.

Any language motivating why METS is important we can borrow from last year's as to why is METS still useful and relevant - METS allows embedding other XML metadata and connecting content with metadata.

Short bios are not needed any more.

Worth thinking about what kinds of examples we should show; don't need to decide that right now.

Want to be sure that we don't appear to repeat content from last year.

We will make edits/review by Wednesday next week (March 8th). Karin will submit by noon (CEST) Friday or earlier if things are ready.

White Paper & documentation

Have not received any comments on METS 2. What does that mean? Do we want to give more time for feedback & start again?

Could proceed with making a cleaned-up version of the schema, producing some documentation, asking for feedback again.

Took a look at insights in GitHub - to see whether people were looking at the schema.

If there is community input we can react to it. Release METS 2.0 as it is, and if there is feedback/changes we can propose extensions/additions.

We can proceed with producing some additional documentation, etc; we will discuss next time whether to release it as 2.0 final or as 2.0 beta.

Transformation

NISO standardization

In the past, we did not want to proceed with formal standardization: we would be too dependent on the formal procedures, review process, many national interest groups, etc; there were concerns about the standard not being available for free.

There were concerns earlier about going through the standardization process with METS going through change.

Question: has anyone been reluctant to adopt METS because it didn't go through a formal standards body?

Quite uncommon for these kinds of metadata to be a standard. METS is a de facto standard because people use it. PREMIS has been in the same situation - has said no to ISO standardization. In this case, NISO is talking about minimal changes to how METS is maintained; that is not something that existed the last time it existed. While with ISO standards there's some possibility for occassional revisions but generally things can only be changed every 5 years.

Experience with standardization committees: ISO could be very heavy; it could take quite a long time. Current revision of OAIS is still not released. Depends on the stakeholders. In some areas there are few stakeholders interested; in others there are many especially if there's uptake from certain companies or interest groups - e.g. PDF/A.

What would we gain from putting it through the standardization process? Possibly acceptance in some contexts such as this European project, but we have not generally gotten pressure or suggestion for METS to be a standard. Experience has been there's more interest in it being a community best practice rather than it being an international standard.

The desire for this particular project (EARC / Lyrasis) was to have standardized methods of using METS In a particular way.

This would appear to be a fundamental change to how the METS board is structured & operate. Important that METS continue to be freely available, open, community standard.

Schematron became an ISO standard, was originally a community standard; now time for Schematron to be revised, but that revision will be kept within ISO and the specification will not be published freely.

Any arguments for this?

It would be easier to get people like this person to accept use of METS in other specifications/standards.

Standardization might drive adoption - e.g. office document files weren't & were used long before it became standard; idea to make it a standard was driven by MS, though it would be an advantage to standardize previously-proprietary formats. Some initiatives start from scratch as standards, and they are never really adopted.

There are some guidelines about thinking about adopting that include is it supported by a standards body, or does it have active maintenance? In the mix as people think about what would suit their needs, but not typically a determining factor. Vendors want stability/assurance of consistency, but we have demonstrated that over the years. MPEG-21 DIDL is an example where adoption was not higher after it became an ISO standard.

How should we respond to this?

General agremeent from the METS editorial board we don't see significant advantage from proceeding with this and that we do not proceed.