Dear WG members,
This is just to let you know that we take maintenance mode seriously, and a new version of the Metadata Standards Catalog is in preparation.
Experience of working with the current version has shown us that while the data model had a kind of idealistic charm, it was not all that wonderful to work with programmatically. The new version will use a modified data model that is easier to work with. The highlights are as follows:
- Relationships between records will move to a separate table in the database, instead of being stored in a record at one end. The benefit of this for contributors is that you will be able to edit relationships from the records at either end (so you will no longer have to add records in a particular order).
- There will be more discrimination between the things you can record about a metadata scheme as a whole, and the things you can record about a particular version of that scheme (ditto for tools and crosswalks). One sacrifice we're making here is to abandon the facility to specify in a machine-readable way the particular version of a scheme that a tool or crosswalk was designed for, as it makes things horrendously complicated. If there is demand we may find a different way of doing it later on. On the plus side, the workflow for editing versions will make more sense.
- We will surface more of the contents of the database for easy access, so you will be able to view the records for organizations, mappings, and endorsements directly. If you know an entry needs updating but can't remember which standard or tool you saw it in, you will be able to find it much more easily.
- The subject classification we use will be a proper profile of the UNESCO Thesaurus, solving some issues we had with the original. Internally the database will record subjects using URIs instead of labels. (We used labels before to make records easier to edit by hand, but it's not best practice.)
- The vocabularies we use for URL types, data types, organization types, tool types and identifier schemes, will have their own database tables, instead of being hard-coded, filtered by regular expressions, or otherwise uncontrolled. They will all be folksonomic, but new terms will have to registered before they can be used.
The entire codebase is being re-written from the ground up, and I am currently working on re-designing and implementing the API. As far as I know, no-one other than me has been using the restricted access API, but if you have been using the open access API, do let me know so I know what level of compatibility I need to provide.