-
Notifications
You must be signed in to change notification settings - Fork 405
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Metadata rework #1262
Comments
See earlier discussion in (closed) issue # 1139. |
My initial "try it out and see what happens" implementation will focus on DublinCore. I'll let you know what I learn. |
I have pushed an experimental starting implementation for y'all to take a look at. It's in my music21 fork (gregchapman-dev/music21) on the gregc/metadataDublinCore branch. Is it easier for folks to take a look if I make a PR (even though there's a ton more work to do)? |
The work in progress can be found in PR #1266 |
Motivation
There is a lot of metadata in scores of various formats (MEI, Humdrum, etc) that cannot be represented in music21 metadata. Let's fix that.
Feature summary
My current idea is to follow JSON-LD (with context dictionary that defines the vocabularies, and data dictionary containing all the metadata), thus allowing different vocabularies, not just the things defined in DublinCore itself. For unknown-by-music21 vocabularies (e.g. Humdrum keys), the importer should map everything it can to standard DublinCore vocabulary, but also put everything in as Humdrum vocabulary as well, since there might be data loss otherwise. The idea is that exporters are required to understand all the DublinCore vocab that can be exported to their file format, and should override with more accurate data from the original vocab (if they understand it). If an exporter's file format has a way to store "external metadata" (e.g. MEI's "extMeta" and maybe even MusicXML's "miscellaneous"), then the non-understood metadata should be exported there (MusicXML "miscellaneous" will need some well-defined way to name the vocabulary, so others will be able to interpret if they can; perhaps using a full vocab URI prefix instead of just a key name, or having a concept of a JSON-LD context stored in 'miscellaneous').
I think we could even make this backward-compatible, if necessary, making the existing Metadata APIs return exactly what they used to from the new internal implementation.
Intent
[x] I plan on implementing this myself.
[ ] I am willing to pay to have this feature added.
[x] I am starting a discussion with the hope that community members will volunteer their time to create this. I understand that individuals work on features of interest to them and that this feature may never be implemented.
The text was updated successfully, but these errors were encountered: