When I think of a good metadata system, here’s what pops to mind. It’s certainly inomplete and likely naïve.
It’s a tree. The root node is a reference to an arbitrary (worry: loops) object: an XML element, the contents of a file, an image, a filesystem path, a compiled function, or whatever. (Mechanism?: either a URI or none, where none defers the linking (“A is B’s metadata”) to some container. And filesystem.) Root node carries a timestamp and some kind of auth, to establish precedence. (Worry: mixing trees. Use special level-2 version-nodes and invisibly use only the judged-best one unless otherwise asked?)
In the rest of this paragraph, “node” means non-root node. Each node is named with either a string or an integer, and points to n nodes, all of them either string- or integer-named. Siblings must share type. (Cross-refence is fine. “date” and “dc:date” can point to a single string.) Nodes whose children are integers can be handled as arrays; the kids must start at 0 and be continuous.
Don’t think of it as having only two kinds of name; think everything has a string name and some nodes have array contents. (Beginning to doubt array thing; can’t remember I used to convince myself.)
Modular standard. Support of bloated version includes support for an assload of string-to-type cast rules (all digits → integer; [-]\d\d*\.\d*e?\d* → float, etc)
That’s no good.
A photo: time, lat/lon/elev-alt, shutter, aperture, focus, flash, lens, body, film/ccd, direction, subjects, hold, manipulation notes, manipulation log (or script), technical natural-language comments, natural-language caption, roll, photographers, rights holders, license, license contact, resolution, codec, codec hints, print dpi, color profile, color space, orientation, reference to other versions, reference to map, kitchen sink, bathroom sink.
Property suites?