Support Metadata On All DSpaceObjects

[mdiggory]

@Mire Support for Metadata On All DSpaceObjects

[peterdietz]

I've noticed that some change that has been slipped in is changing from a local ourContext to getContext() method. I guess I'm fine with it, is there any rationale for injecting that change?

Is there any concern with database drift since oracle will use table name RMetadataFieldRegistry and postgres will use: ResourceMetadataFieldRegistry ?

I haven't yet checked this out to give a solid analysis yet.

[helix84]

I thought Oracle's limit on table name was 30 bytes. "ResourceMetadataFieldRegistry" is 29 ASCII characters, so why not keep it?

[helix84]

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.

[mwoodiupui]

Also curious about the need for parallel metadata tables.

[mdiggory]

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]

I'm going to delay this contribution and close this pull request

[mwoodiupui]

"We need different 'containers' for metadata...." Why?

"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]

mwoodiupui: "We need different 'containers' for metadata...." Why?

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"