Date: Thu, 28 Mar 2024 19:40:07 -0400 (EDT) Message-ID: <1103342985.29220.1711669207785@lyrasis1-roc-mp1> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_29219_1428026010.1711669207784" ------=_Part_29219_1428026010.1711669207784 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This page is outdated and kept for archival purposes only. It contains the proposal and discussion of the "Metadata for all DSpace obj= ects" concept. The actual implementation of this concept in DSpace 5 is out= lined in Metada= ta for all DSpace objects.
This is based on Claudia's comments in the commiter list and the topic d= iscussed elsewhere. Goals should be to expand on this and relate it to othe= r projects/efforts. For instance, the async release proposal will now inclu= de establishing a true "API" for DSpace legacy objects and placing this in = the "modules" directory where other projects can depend on it.
- enable metadata for all dspace objects (communities, collections,
items, bundles, bitstreams, metadatavalues, epersons, groups).
- revise the default metadata registry see
https:/=
/jira.duraspace.org/browse/DS-433
- not only manage the metadata schema, but also related vocabularies
(like DCMI Type) and encoding schemata.
- enable multiple metadata schemas per default (dcterms, an
administrative one and a couple of standard namespaces like those used
for prism)
- think about whether standard namespaces (supposed the namespace is
complete in the default registry) should be editable at all. An instance
can always use it's own namespace.
- manage metadata field related configurations like hide option,
display, browse, search etc. in the db rather than in dspace.cfg. At the
moment one can delete/move a field which via the UI which is used as
configuration parameter
- get rid of the deprecated DCValue