Taxonomy or Vocabulary like tags and collections

Omeka Classic
1

It seems that one thing that’s really needed is a taxonomy/vocabulary system that works like tags (multiple “tags” per item, auto-complete, “add new” in-place, edit all from central location, etc.), along with the metadata of Collections – so that each vocabulary item also has it’s own “page” with Dublin Core fields and files, etc., like how Collections are. “Tags” are good, but they can’t easily be limited to relevant fields, and they don’t have their own metadata.

For example, I have a bunch of “Book” items and I want my “Authors” element to allow me to easily assign an author for whom I’ve already entered several books that she’s written – so it would be nice to have her name show up as an auto-suggest in the Author element field. This particular book has multiple authors, so this can’t be solved with Collections, much less since the book already belongs to the “Modern Fiction” Collection. My next book Item is by a new author, and it would be nice if, like with “Tags,” I can simply enter the new author and have the auto-suggest stop showing suggestions once it’s clear that it’s a new entry. Tags are not good here, because I want to link to the Author’s page, with it’s own meta-data and list of Items belonging to it (as if it was a Collection).

Make sense? Is there currently development going on for this? After working with Omeka for a while this seems like a glaring omission.

2

After putting a bit more thought into it I’ve created a brief spec to get my thoughts organized:

–Elements would have a new checkbox: “Use taxonomy”

0usetax.png1170×372 58 KB

–When this is checked, a brief bit of explanation is shown – something like “Elements that ‘Use taxonomy’ will autocomplete based on values from the same element in other records” – and the input box turns into a simpler text entry (probably “Use HTML” should disappear here too)

1usetaxchecked.png1160×372 41.5 KB

–The input box is an auto-complete – like “tags” (but here only one entry is allowed per element text). The autocomplete values are taken from any already-existing values for this element in other records – i.e., in this example, any existing entries from the “Format” element in other records (note that I say “records” instead of “items” because the element might here belong to a File or a Collection or any other “record”)

2usetaxautocomplete.png1160×372 43 KB

–If the user chooses an auto-suggested value (or types a matching value?), then the value shows up that same way a “tag” does and is removable (x) or editable (click the text) in the same way tags are.

3usetaxautocompleted.png1160×372 42.2 KB

–If the user enters a value that is not already existing for that element in that record-type, the value shows up a different color to indicate a “new” taxonomical term. Once the record is saved, the term will be green as it will now be an “existing value” and will also now show up in the auto-complete for that element for that record type.

4usetaxnewterm.png1160×372 43.6 KB

All the Taxonomy terms will be listed in the sidebar of the admin, like Collections – each term has it’s own meta-data, and each taxonomy term has a “record type” and an “element” that it’s associated with. Each term will have it’s own theme page, like Collections, with it’s own meta-data and a list of all records that have an element that matched the taxonomy.

For elements that “Use taxonomy,” the themes pages create links to the Taxonomy page.

If a user UNchecks “use taxomony” then that element reverts to text, with the values of what were the taxonomy terms.

What do you think? Is this worth pursuing? My clients always want this (though they don’t know how to articulate the details as I’ve done here). Would this be a good plugin? Or do you think it would need to be part of the core?

3

I should have said this part first :slight_smile:

This solves the following issues:

  1. Takes care of cases where people want a single item to belong to multiple Collections – taxonomical terms can group items together (not replacing Collections…): imagine an archive of art – “Picasso” could be the “Creator” of many painting items and could then have his own “Page” with his own meta-data. Further, if he was one of several “creators” of, say, a pamphlet, he could be included there too and that pamphlet would be lumped onto the “Picasso” page (or we might call it: “the taxonomy entry for Items with a ‘Creator’ element set to ‘Picasso’”)

  2. Solves several “tags” problems:
    a) Tags don’t have their own meta-data like how Collections do – so a Tag page can’t show a ‘description’ of the tag (or other metadata on the tag)

    b) Tags are available on the Record-level, so the way they lump things isn’t as fine-grained as this. Something Tagged “Picasso” might mean that it is a photo OF him or interview WITH him, but “Creator=Picasso” is much more specific.

  3. Makes creating taxonomies easy – you can create and edit terms as-you-go. (We’d probably want some management features, like consolidating two taxonomical terms [misspellings, etc]). The taxonomy plugins I’ve seen require you to create lists of taxonomies before creating records, which is difficult for many. If a very particular taxonomy is required, then the user could go to the “Taxonomies” sidebar and create the terms and which element and record-type they belong to first.

4

Hi, @jamienk.

I was recently playing around with the Simple Vocab Plus plugin, and I was wondering whether it would have been possible for the input fields to suggest values already available in the repository instead that values taken from an external list. Unfortunately, UCSCLibrary is not developing that plugin any further (see my discussion about it here: https://github.com/UCSCLibrary/SimpleVocabPlus/issues/9).

Now that I’ve found your solution, I was wondering whether it would be possible to merge them, i.e. have just one plugin that was offering to the admin the chance to assign to any given input field one of these options:

  • free entry field;
  • taxonomy field (no chance to add new values);
  • taxonomy field (with chance to add new values);
  • external list field (located in the repository, as a list or a file, or in the cloud, with no chance to add new values);
  • external list field (located in the repository, as a list or a file, or in the cloud, with chance to add new values).

I have not the knowledge needed to implement it, but would it be something you might consider?

Thanks.

5

@jamienk @DanieleB I’m working on a project where we’d really like to have basic metadata (image + description at the minimum) associated with a selection of tags; something similar to the approach described above in this thread.

Wondering if either of y’all have thoughts on the simplest way to implement something like this? My current thoughts for options were to either:

  1. Create a custom plugin based on starting with the existing SimpleVocabPlus codebase, but extend the TaxonomyTerm model to include a description & image (would also need to create new routes/views to edit individual taxonomy terms)

  2. -or- Create a new item type “Tag” or “Topic”, which would hold the actual metadata, and hack together the logic required to create a 1:1: link between these and actual tags (this approach seems slightly simpler but also more prone to potential errors).

6

Hello, Tim.
Unfortunately I don’t think I have a solution for your problem, but I’m still working on my fork of SimpleVocabPlus and, in the next days, I should make available a new release, so if you decided for solution n. 1 I suggest to take a look to https://github.com/DBinaghi/plugin-SimpleVocabPlus to see whether it’s what you might need.