Nevermind my last commment, I actually recommended that there shouldn't be separate tables, but existing metadatafieldregistry and metadatavalue be used instead. There's no reason to split metadata for items into one table and for everything else into another table.

I want to clarify my position on what the requirements are for metadata on all DSpace Objects

1.) We need different "containers" for metadata (Descriptive, Technical, Administrative) that can be named and be attached to any DSpace Object. These align with METS sections and would be serialized into our SIP/AIP/DIP as such.

2.) We need just plain old "properties" on Objects, which workflow and system can use and which are not exposed publicly.

3.) Finally, we need "Profiles" or true "Schema" that can be enforced on a DSpace Object (i.e. Content Types), these define the fields that can be added for Communities, Collection, Items, Bundles and Bitstreams, and likewise, can be extended to create different "Types" of Items and Bitstreams in DSpace.

At this point, the existing system abuses the concept of "schema" confusing it with "namespace", The closest thing DSpace has to a schema is the input-forms.xml that enforces input values that can go into Item metadata regardless of what MetadataSchema is in the Registry.... To be clear "MetadataSchema should be "MetadataNamespace" and DSpace has no "Schema" at this time. Don't confuse XML Schema with DCMI Namespace. Its a poor design.

The point of presenting this example is that we did actually create a typing mechanism for identifying the fields and can be used on DSpaceObject types.

mdiggory: because, all metadata is not just "Descriptive", METS provides "Container-ship" and "Assignment" of sets of metadata in different formats (premis, mods, dc, etc) these sets serve various purposes within the METS wrapper.

mwoodiupui: "We need...properties...which are not exposed publicly." We need ACLs on fields. Every time we hardwire what is or is not visible, someone comes up with an exception. Just make it all configurable.

mdiggory: Yes, we do need ACL's on fields. But we also need to clearly separate the set of internal system level configuration properties from sets of publicly and/or semi-publically disseminated content metadata. This is so that theres a clear place to store "configuration" details vs "metadata"