Date: Thu, 28 Mar 2024 20:29:19 -0400 (EDT) Message-ID: <773608683.29278.1711672159062@lyrasis1-roc-mp1> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_29277_1005926128.1711672159061" ------=_Part_29277_1005926128.1711672159061 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Contents
A simple enhancement proposal to add support for multiple (flat) schemas=
.
Current assignee: Martin Hald. Basic implemenation complete, alpha version=
available as http://sourceforge.net/tracker/index.php?func=
=3Ddetail&aid=3D1242663&group_id=3D19984&atid=3D319984 a pa=
tch on SourceForge.
The basic idea is to generalise the code and DB tables around Dublin Cor= e. Conceptually speaking, a new column is added to
DCTypee= gistry
, and the same mechanisms used for Dublin Core may be used for other sch= emas. I believe Jim+Downing has alrea= dy implemented something along these lines.
Backwards compatibility is important and not actually too difficult. Mos= t of the 'under the hood' changes can be made with no need to change any UI= code or other code in
org.dsp= ace.app.*
.
From a backwards-compatibility point of view, keeping the table names th= e same might be easiest. However, changes to table names are masked from mo= st code through the org.dspace.content.Item API. We may be able to use D vi= ews for other cases. There would need to be refactoring in a couple of othe= r areas, but from an architectural consistency and code manageability / und= erstandability viewpoint, I think this would be worth it. So that's what I'= ve assumed below.
A new table,
Metadat= aSchemaRegistry
is added, and
DCTypeR= egistry
is renamed
Metadat= aFieldRegistry
and modified to relate to the schema registry. Note the UNIQUE constrain= t on element / qualifier is removed (can easily see >1 schema having "ti= tle").
------= ------------------------------------------------- -- MetadataSchemaRegistry table ------------------------------------------------------- CREATE TABLE MetadataSchemaRegistry ( metadata_schema_id INTEGER PRIMARY KEY, namespace VARCHAR(256), short_id VARCHAR(32) -- e.g. 'dc' ); ------------------------------------------------------- -- MetadataFieldRegistry table ------------------------------------------------------- CREATE TABLE MetadataFieldRegistry ( metadata_field_id INTEGER PRIMARY KEY, metadata_schema_id INTEGER REFERENCES MetadataSchemaRegistry(metadata_s= chema_id), element VARCHAR(64), qualifier VARCHAR(64), scope_note TEXT );
DCValue=
would be renamed to
Metadat= aValue
, but remain the same. (Note that
source_= id
is removed since it's an architectural relic.)
------= ------------------------------------------------- -- MetadataValue table ------------------------------------------------------- CREATE TABLE MetadataValue ( metadata_value_id INTEGER PRIMARY KEY, item_id INTEGER REFERENCES Item(item_id), metadata_field_id INTEGER REFERENCES DCTypeRegistry(dc_type_id), text_value TEXT, text_lang VARCHAR(24), place INTEGER );
We can create a view
DCValue=
for backwards compatibility:
------= ------------------------------------------------- -- DCValue view ------------------------------------------------------- CREATE VIEW DCValue AS SELECT MetadataValue.* FROM MetadataValue, MetadataFieldRegistry WHERE MetadataValue.metadata_field_id =3D MetadataFieldRegistry.metadata= _field_id AND MetadataFieldRegistry.metadata_schema_id =3D 1;
We could define '1' as a special value for
metadat= a_schema_id
for Dublin Core. (Can we make
metadat= a_value_id
appear as
dc_valu= e_id
? Not that it probably matters.)
By definition anything in the DSpace application/interface layer
org.dsp= ace.app
won't be affected as it is using the
org.dsp= ace.content.Item.getDC
method. Of course additional functionality will be needed in the UI (adm= inistration UI etc.) to realise the schema support but everything should wo= rk as before when the relevant changes are made elsewhere. Care will be nee= ded to do everything in a way that doesn't impact performance. (Don't want = to add to ScalabilityIssue= s1.4!)
New class
Metadat= aSchema
. Very much along the lines of existing
DCType<= /pre>
and other DSpace Java objects. _Maybe belongs in
?_
DCType<= /pre>
becomes
Metadat= aField
.
getMeta= dataSchema
and
setMeta= dataSchema
methods added.
loadDC<= /pre>
needs updating (see below).
Maybe create a backwards-compatible class
DCType<= /pre>
?
org.dsp= ace.content.Item
getDC()= /setDC()
Metadat= aField
Metadat= aSchema
Metadat= aValue
DCValue=
Metadat= aSchema
DCValue=
Metadat= aValue
Will work with DC with no changes as it uses APIs and not direct D acces= s. Will need to be modified to use new metadata schema values.
dspace.= cfg
search parameters can be changed to index new schemas, e.g.:
search= .index.1 =3D author:dc.contributor.* search.index.2 =3D author:dc.creator.* search.index.3 =3D title:dc.title.* search.index.4 =3D medium:vracore.material.medium
Code and table views will need alteration.
[dspace= ]config/registries/dublin-core-types.xml
dublin_= core.xml