[Dspace-devel] [DuraSpace JIRA] (DS-433) Update DublinCore Registry to Implement lates DC Standards

[Bram Luyten (@mire) (Commented) (DuraSpace JIRA)]

[ https://jira.duraspace.org/browse/DS-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22105#comment-22105 ]

Bram Luyten (@mire) commented on DS-433:
----------------------------------------

Some initial comparing work:
https://wiki.duraspace.org/display/cmtygp/NewDublinCore

In short:
- there seems new & more focus on Domain (limitations on the type of resources a field can be used for) and Range (which values are allowed as contents of a field)
- For the older set of 15 DC elements, it just seems a matter of implementing/enforcing range on some of the properties (e.g. ensuring correct dc.date values, language values, ...)
- Lots of the newer DC Terms are already present in DSpace. Like many of DSpace qualified dates, like dc.date.issued dc.date.available, are now defined as individual elements. This is a great opportunity to ensure that no information gets lost while element qualifiers do get lost when harvesting.
- DCMI still seems to struggle with the idea of relations between fields. Some fields are indicated that they should be used with non-literal values (e.g. things instead of strings) but they haven't come up with a formal range declaration.

> Update DublinCore Registry to Implement lates DC Standards
> ----------------------------------------------------------
>
> Key: DS-433
> URL: https://jira.duraspace.org/browse/DS-433
> Project: DSpace
> Issue Type: Improvement
> Components: DSpace API
> Reporter: Jeffrey Trimble
> Priority: Major
> Original Estimate: 17 weeks, 2 days, 8 hours
> Remaining Estimate: 17 weeks, 2 days, 8 hours
>
> DSpace's current implementation of Dublin Core was a subset or simplified version of the Dublin Core standard created by OCLC. Since the first release of DSpace, Dublin Core has undergone major revisions. DC version 1.1 was implemented in 2007 with 15 base elements a subset of the larger DCMI. Some users are currently misusing the DC standards, or lack knowledge how to use it properly due to the age of the current element set and the descriptions contained therein.
> I recommend that the DSpace Developers look at using the full implementation of DCMI for the next major release after 1.6. Additionally tools will need to be provided
> for conversion of existing DC Metadata Schema.
> Also, it would be advantageous to build into the software a validation of DC elements in a stricter sense than is now being used.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.duraspace.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[Mark Diggory (Commented) (DuraSpace JIRA)]

[ https://jira.duraspace.org/browse/DS-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22113#comment-22113 ]

Mark Diggory commented on DS-433:
---------------------------------

Bram, this was our hope by the utilization of "References" in DSpace 2.0, "References" would be resolvable Range of the resource. But alas, yes, the focus is on having a reference to some sort of thing and is very Semantic web centric.

IMO, we would be best served to work to not attempt to build a "Relational Data" model into the DSpace Metadata Value table itself, IMO, I think the trajectory that DSpace should take is to align it with Fedora approaches. This means.

1.) DSpace MetadataValue, Field and Schema are enhanced to support being grouped into "sections".
2.) Metadata is persisted in Bitstreams (Datastreams) as well as in the database.
3.) The format of those bitstreams is specific to their "role" in DSpace, RELS-EXT/INT for semantic metadata, mods for descriptive metadata, simple DC elements for internal Fedora search indexes. The groupings are specific to the Hydra Content model.

At OR11 there was a considerable dialog between Mark Leggot, Matthew Zumwalt and myself that was fucused on how to align DSpace properly with Fedora and Hydra, the primary result of that dialog is that we need to look more seriously at adopting the features of the Hydra Common Content Model

https://wiki.duraspace.org/display/hydra/Hydra+content+models+and+disseminators