Susan,
Here are my $0.02 on redefining metadata fields with labels. I also
recommend the following to simplify the manner in which your customizing
your DSpace instance. Limiting changes to i18n, input-forms and dspace.cfg
I question relabeling metadata fields as a good practice. The topic came up
when I was at MIT when one department wanted to have dc.contributor.advisor
be "Supervisor" and another wanted it to be "Advisor". At first blush this
seems like a way to make everyone happy, but it ultimately causes a
divergence in the semantic meaning of the field. Its more apparent when you
see things like:
from the sword metadata schema added to dspace...
<dc-type>
<schema>dc</schema>
<element>type</element>
<scope_note>The type of the item, as defined by the eprints application
profile</scope_note>
</dc-type>
from the original
<!-- Used by system: do not remove -->
<dc-type>
<schema>dc</schema>
<element>type</element>
<!-- unqualified -->
<scope_note>Nature or genre of content.</scope_note>
</dc-type>
Do I take this to mean I cannot just use any dc.type anymore? Or explicitly
just those defined in the sword eprints application profile (
http://www.ukoln.ac.uk/repositories/digirep/index/Eprints_Type_Vocabulary_Encoding_Scheme)
How can I know that dc.type should have a type as defined in the eprints
application profile or those recommended values found in the DCMI elements.
Whether we are talking a favored Label, or a more explicit redefinition of
the field. Without a good solution for application profiles in DSpace,
changing the meaning of the field in a specific context is a a common
miss-step (IMO) many seem to make..
dc.contributor.author and dc.contributor.advisor only have usage in DSpace
and possibly came from a rather "prototype version" of the Library
Application Profile back when DSpace was originally developed:
http://dublincore.org/documents/2004/09/10/library-application-profile/
I would recommend that if you do want to have semantically more specific
meaning for various types of contributors to your work, that you create
semantically specific dc.contributor qualifications for them
dc.contributor.corpAuthor
1.) scope it appropriately
2.) adjust your input forms for the collections you wish to use it in. (also
allowing for separate CV to be attached)
3.) adjust the i18n files to add Labels for it.
4.) adjust the search and browse indexes you wish to have it show in
(reindex DSpace)
To those who recall that some members in our community recommending not
allowing "local qualifiers" in the DSpace DC schema (myself included). I
expect us to have a migration route available for the usecase when we revamp
DSpaces metadata schema capabilities sometime in the future. For the time
being however, its best to allow the activity to support the old school
"dumb-down" of QDC to plain old DC in OAI and other crosswalks...
Cheers,
Mark
--
Mark R. Diggory
Head of U.S. Operations - @mire
http://www.atmire.com - Institutional Repository Solutions
http://www.togather.eu - Before getting together, get t...@ther
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
