I think I’ve never quite understood what is the difference (if any) between the content of the DC field Type and the Item Type field in the Item Type Metadata tab.
It seems to me they’re the same, despite the slightly different name/label. So, we’ve ended up creating a controlled vocabulary for DC:Type that perfectly matches the Item Type list.
Is it correct? Or is there any difference between the two of them? And could anybody provide me with examples of such a difference?
If there was not a difference, why then having the two separate input fields? Would it not be easier to have just the DC:Type one and, when changing its content, automatically change the elements shown in the Item Type Metadata tab? That would make things easier for users, and remove the chance they forget to match the two fields.
Even better, in such a case an option to compact the two tabs could be also useful. I understand some would still prefer to have the DC fields in one tab and the non-DC fields in another tab, but (as, for instance, AvantAdmin plugin shows) some other could find it more useful to have all fields displayed in the same tab, so maybe a configuration option to provide such a choice could be useful.
Hope someone can cast some light on my doubt.
Omeka makes a distinction between DC:Type and Item Type Metadata because it is a multi-user and multipurpose application. Not every user wants to describe items of the same DC:Type the same way. If Omeka tied the DC:Type field to how the item is described, there would be only one way to describe, for example, a Person, Text, or Event. This is far from ideal for an installation with more than one user or purpose.
I could see the reverse: like, on the Item Type Metadata tab, the user could choose to auto-populate the DC:Type field once they select an Item Type.
Thank you, Jim, for your answer.
I see your point, there. But then, would you recommend to keep a limited vocabulary for DC:Type, and expand it for Item Type Metadata? Or would it be better to keep them aligned?
F.i., one could distinguish between “monograph” (nonserial publication complete in one volume or a definite number of volumes) and “periodical publication” (serial publication that appear in a new edition on a regular schedule); would you suggest to keep only “text” in DC:Type, and then distinguish them in Item Type Metadata, or rather to add them both to DC:Type too?
Recommended practice for DC:Type to use a controlled vocabulary such as the DCMI Type Vocabulary. So, unless you plan on using a more finely grained vocabulary to define the type of your items, I would keep “Text” in DC:Type and then distinguish them in Item Type Metadata.
Again, it makes sense to me, so thank you very much Jim for your notes.
There’s just one thing that doesn’t really fit into this scheme: the Item Type Metadata doesn’t appear in the
Items/Show page, so the added granularity gets lost. I suppose the reason is that that particular information gets recorded in a different table from all elements. Of corse one could always change the code of the theme’s
Items/Show page to display it, but I find it strange that is missing by default.
The item type only appears when at least one of its elements has a value. It is uncommon for an item to be defined as a specific type and not be described by that type. Regardless, I do understand why it’s confusing that the item type is not visible.
I recommend that you describe your items using at least one item type element. Alternatively, you could refine your type by adding a DC:Type input (items can have more than one value for an element). So your item can have two DC:Types: “Text” and “Monograph.”
Jim, sorry for asking, but are you sure of that? We’ve got Items with specific Item Type where no element as a value, and Items with other Item Type whose elements have values, but in both cases the value of Item Type is never displayed (only DC:Type gets displayed).
Our theme is not a vanilla version, as it has been customized, but I’ve checked “Thanks, Roy” theme’s code on GitHub and it does seem to me that the Item Type information is never shown, regardless of which elements have value. As said, I believe that value is stored in the database inside the
Items table, in the
item_type_id field, so it does not get listed when all elements are.
Still, as said I can surely customize our
Items/show page, but wouldn’t it be better if that information was displayed by default? What do you reckon?
all_element_texts() will print out Item Type Metadata (this line) .
And, yes, I do think the interface should display the item type, even if there are no values. It’s something we are considering.
I suspect we’re talking about two different pieces of information here: I cannot see how
all_element_texts() could display the chosen Item Type (I’m talking about the dropdown/combobox at the top of any Item Type Metadata edit tab), since that is not an element (nor an element set ). Same reason why the Public or Featured info have to treated separately: they’re stored in a different table from elements, so any loop showing all elements would just miss them.
all_element_texts uses the item’s selected Item Type when displaying the heading for the “Item Type Metadata” element set (i.e., “Document Item Type Metadata”)
Ok, now I understand what Jim meant, thanks to both of you.
It still seems to me a bit complicated, though, if one was to use the Item Type for increased granularity, as it was suggested: first one has to enable the Show Element Set Headings option, then possibly remove the “Item Type Metadata” part from the string… It works well if one only wants to separate the different element sets, but if instead was interested in just the Item Type name it doesn’t work very well.
John, where would you suggest to alter the code to treat that Item Type name just like any other element?
You could do it in record-metadata.php… I’d probably recommend to just display the type name directly in the item show page if that’s what you want, though, with
echo metadata('item', 'item_type_name')
I’ve gone for the theme’s custom
record-metadata.php, in the end, as this way I can call
all_element_texts and position the Item Type name just before starting to display all Item Type elements.
Still to be solved: turn the Item Type name into a link (Search By Metadata plugin won’t work here, as the name is not an element), and also on Admin side it doesn’t show up on
Thanks guys for your help, really appreciate it.
This topic was automatically closed 250 days after the last reply. New replies are no longer allowed.