I do wonder about what you said, though: Would it be useful to be able to specify two different file paths or URIs for the same item? I'm leaning towards no, because, when clicking on an entry, you want it to start playing, so the choice is made when adding the file, rather than when playing it. The problem with multiple file paths is that both have the same weight, so how do you choose?
I guess you'd choose the same way you choose between the formats already, based on whatever is available/found.
Yup, which I think is good, since URI schemes already exist for many identifiers, and more can be added.
> Would it be useful to be able to specify two different file paths or URIs for the same item?
I think so. Maybe one is one removable medium and the other is on another.
> The problem with multiple file paths is that both have the same weight, so how do you choose?
If they have equal weight, does it matter which you choose?
Notice that the cardinality is "zero or more."
You can represent hashes using the named-information URI scheme (https://tools.ietf.org/html/rfc6920), e.g. ni:///sha-256;u88lYWn4xAlto-6Bs79KHHYDAu28US71ui5Be6C-ZVw.
Your filepath could be file:///Anciients/Following%20the%20Voice.mp3; your mbtrackid could be musicbrainz:b00a2b97-53f1-485a-9121-1fe76b55e651 (since I don't think an authority makes sense in this case).
This would also permit multiple entries for certain types of identifier, which doesn't make so much sense for hashes (although it's possible for the same recording to have two different MP3 encodings, so … maybe it's not crazy), but would be nice when e.g. a song is found in multiple places in the filesystem, or can be retrieved from multiple locations.