Hi,
How can I add/customize elements to the DC schema?
Hi,
How can I add/customize elements to the DC schema?
Hi QCDA,
You currently cannot customize elements to the DC schema. You can, however, add elements to the DC with the DublinCoreExtended plugin:
http://omeka.org/add-ons/plugins/#dublincoreextended
Hope this helps,
Jeremy
There is no user interface to customize existing element sets (the DC schema is an element set). We do this in an attempt to enforce some rigor in the standards represented by the element sets. There are ways to do this, and even to customize the form fields for individual elements, but this requires knowledge of PHP, Zend Framework, and the Omeka plugin API.
However, we do allow users to create and customize elements for item types. These elements are not available for all items (as they are for element sets) but it may be what you're looking for.
I am hoping that Omeka will allow me to eventually customize the existing element set for DC. I have a customized DC with the needed mapping to the DC standard. It adds a layer of complexity to have to remember which DC element maps to our customized DC element.
I find this discussion very important. As the 'messenger' between the Standards, and I completely agree with the need to enforce and maintain standard and advocate this at every opportunity, I constantly run up against entities who have adopted their own home brewed standards.
When I plop down someone down in front of the DC Element Set, as the messenger, I get killed. And end up spending chunks of time discussing the needs to ameliorate towards established standards.
In my opinion, having the ability to customize Element Sets, if to do nothing more than add language to a field, like for instance 'Spatial Coverage' which in layperson's terms can mean 'Location', just being able to add 'Location' to this existing field would solve the perpetual griping I hear trying to encourage best practices within an institution or organization.
This is a constant when I face people. So, being able to customize Element Sets is in my opinion a big deal, and to maintain a rigid posture towards Element Sets and how challenged they are to alter now is, well... I would like to cast a vote for making these customizations easier, as in through the admin UI. Creating a plugin is quite excellent. But I feel customization needs to be a level or two more accessible.
My $0.02. And also the $0.02 of a growing number of people I am bringing to the Omeka dance. It is the #1 topic in my discussions.
Thankx. Omeka is a terrific framework. Just terrific.
regards, david
@drhii Hear, hear!
I would love to be be able to change the label display for the DC Elements as well. If possible, can it be done on a collection by collection basis?
David & hcleary,
We appreciate your entreaties, and we're listening.
This discussion brings to mind Omeka's future plans for internationalization and localization. Part of enabling multiple languages on an Omeka website would be the inclusion of translation tables that encompass the breadth of the written copy, including element labels. I'm imagining a customized translation table for recalcitrant users who must have "Location" instead of "Spatial Coverage."
But we'll consider your idea to provide an interface that can switch out element labels.
Jim
Thank you for your response Jim.
Yes, I can understand how this relates to internationalization and localization.
As you articulate, imagining a "customized translation table for recalcitrant users who must have 'Location' instead of 'Spatial Coverage'" is something I run in often. Quite often. I am ALL for working to get people to standardize. It is also pulling teeth, especially for organizations who have been working on paper, spreadsheets, or yes, wordprocessor, and have employed a homebrewed set of standards.
Kicking and screaming is putting it mildly, to encourage a best practices migration to say, Dublin Core, DC Extended, CDWA, and so on.
Instead of caving in and crafting a plugin that caters to the Mom and Pop Museum standard, which I push totally against, just being able to assign the word "Location" AND "Spatial Coverage" to the same Element would create a meeting half way. One foot in Mom and Pop, the other is "the way the world works".
So I would encourage not just an either "Spatial Coverage" OR "Location", but the specter of both residing together.
Now that I have beat this horse, will add one more smack. This challenge is perhaps the #1 problem I face in getting entities to adopt something new. As in an asset manager. Being able to either switch out or append to element labels would break a log jam that gets repeated more than anything else in my pitching to entities who are wanting to make the leap, but trying to rock someone's nomenclature world sometimes ends up with arrows in backside. I had a museum board fixate on this very issue just yesterday. I know, boo hoo. But is a pretty real thing.
My $0.06. Thankx for fielding this concept.
regards, david
I'm glad that you are working on this. I see it more as a user-friendliness issue rather than as localization.
As a cataloger, I care that MARC tags are properly used. As a librarian, though, I don't want my users to have to translate those numbers into something meaningful. If I had my druthers, my OPAC would display 1xx and 6xx fields in 1 "Author(s)" field rather than be separated out into main entry and additional authors.
I want to use field labels that are meaningful to the end users. DC can be in the background, allowing us to map and share data with ease.
I am also wanting to edit the DC element descriptions that display on the back end -- I've found them in the database table and can edit them with phpMyAdmin. Is there a better way to do this? Will I break anything if I edit them there?
I looked for language files -- but in 1.5 I don't see this yet.
I foresee no problem with editing the description column in the elements table. But take care not to modify anything else in that table. Things will break.
In fact, I suppose someone could write a plugin that allows administrators to modify element descriptions in the admin interface. This would only be necessary for elements belonging to element sets, not item types.