marksparkza
commented
3 months ago The concept of a unified, standards-independent ontology is now being implemented with respect to packages rather than records - see the remarks for commit af333d9986e0f8749d26af0a383d928120ab1d10.
This makes sense on a number of levels:
- Existing record metadata do not need to be migrated into record tag instances.
- Related to this, package metadata does not need to be carved up into record tag instances as part of the submission/archival workflow. Instead, package tags are used to generate JSON metadata for records, which is far simpler.
- Existing catalogue publication code - which relies on records already having standardised JSON-based metadata - can remain as is.
- Existing record admin interfaces - being used successfully and happily by the curation team - do not need to change.
- Modelling metadata components using package tags provides a more straightforward path to an upload UI than do large, complex JSON schemas.
- This approach is also congruous with the modelling of resources as standalone entities related to packages rather than lumping them into JSON blobs.
- Tracking changes to individual metadata components is likely more meaningful for packages than records, since packages are generally provided by external data providers, while records are generally managed internally by data curators.
The record-schema link is removed. The ODP tagging framework provides a way to define a unified, standards-independent ontology for describing digital objects.
ISO 19115, DataCite, Darwin Core, etc, can be used to validate incoming package metadata from data providers. Thus, we can publish an upload API based on internationally-recognised metadata standards. Similarly, we can publish catalog API output endpoints conforming to recognised standards. There is, however, no advantage in maintaining metadata records internally as JSON blobs.
JSON is a transport format which we are currently using as our internal model. It's difficult to make ad-hoc queries for deeply nested values, and it's practically impossible to track changes to individual elements, to mention a couple of challenges with this approach. Using tags to store metadata values, we can standardise our internal vocabularies; we get per-client and per-user tracking of individual field changes; and we can systematically model, normalize and reuse components of complex elements - affiliations, contact info, and so on.