The Search by Metadata plugin produces links that do searches over Items looking for Items having the same natural metadata value. The result is a hyperlinked structure with each chunk of the structure being a search result list. The objects in the search result list are Items.
This is a nice result for a visitor exploring Items in search result lists. It is easy to produce by simply installing the plugin. The plugin generates a big effect with little development effort. The items in the search result list are found based on their having a particular metadata value that is part of their original definition when entered into the system.
This feature has a model of a single item type, so that all search result lists contain similar items. Or more precisely, it has no concern about more than one item type. If there is more than one item type, this aspect is not surfaced in any way.
The Item Relations plugin also produces a way to search over Items. Rather than searching over Items having the same natural metadata value (with no need to add any special values), the search is based on looking for Items that have been registered to be related. This is searching for Items that logically have the same special metadata value, which was added specifically to tie together a set of related Items. This feature has a high cost of ownership, measured in manual data entry transactions.
This also is a nice result for a visitor, providing a navigation path of hyperlinks to see chunks that are curated result lists. Beyond installing the plugin, the archive developer must also actively create the relationships that define the curated result lists. This is a lot of work, both to build the relationships at the start and to maintain them.
The navigation of this plugin provide the same flavor navigation as Search-by-Metadata, in that each link does a search and displays a result list of items.
This plugin allows for a model of multiple item types. A result list is defined by curation and registering the curated relationships. A curator may establish item result lists that partition the inventory of items into item types that go into different result lists. As you have imagined it, you could relate an artist item type to a set of art item types. Linking from an artist item, you can view a result list of art items. From an art item, you can link to a result list of artists, which will have a single item in the list. But it will be a displayed LIST of artist items, sized one, which is not what you want.
What you are wanting is to surface your art archive to visitors so that a particular Art Item metadata field, the Artist, is a first class object in the system. You will define an Artist item in the system for each possible Art item's Artist metadata value and allow visitors to access (SHOW) the related Artist item, from the Art Item, such that it is as important as the Art Item. Further, the Artist Item is a way to surface navigation to a group of related Art items.
I'm just a user of Omeka myself, trying to figure out how to use it, as it exists, to provide a digital archive in a way that shows Items in a useful way. As a software development contractor, I've used Omeka as a way to get a working digital archive web site up with less effort than building it from scratch. Like any such approach, customizing a large existing code base to do something different requires effort to learn the code base.
The effort to customize and change Omeka is larger than might be imagined for a product that costs nothing and that easily generates a working web page in minutes. The illusion of Omeka being "easy" is just that - an illusion. However the promise of Omeka being flexible and extensible is real. The 6,000+ source files provide huge amounts of functionality to take advantage of, and to overcome.
The Search-by-Metadata plugin is your best starting point for creating the effect of the Artist being a first-class object in the archive. Create a new plugin that starts with that code and change it to something that matches what you need. Call it something like Show-Artist-by-Artist-Metadata.
There is no need for creating a curated list of related items by hand, which is what Item Relations would involve. The relationship between Artist and Art items is inherent in the natural definition of the art. There is an Artist metadata field that exists and is filled in for each Art Item.
The Search-by-Metadata plugin generates an http link that requests a standard item search and ends up at the standard search result list page to display a list of found Items to browse.
To meet your requirements, the new plugin needs to be changed to generate an http link that requests to SHOW an Artist item using the specifics your system has for encoding the artist's identity into the Art item's Artist metadata field. It would do this only for an Art item's artist metatdata field.
A custom view page to Show-Artist-Item needs to be created. It can show whatever is desired, such as a bio or history of the artist, and include a list of art by the artist. This is done with PHP code in a custom view file.
Those two paragraphs are a high-level pointer toward the easiest way to get what you want from the current Omeka product. "Easiest" is the path with the least effort. Not the path with no effort. Those two paragraphs expand into plenty of detailed issues, and a design and development effort.
This is a quick evaluation of where the easy path is. Further details about your ambitions may discount this approach, or suggest other approaches such as adding tables to the schema to make the Artist a true first-class object, encoded into a database table. One example of an Omeka user following this approach is an organization building a digital archive of geographical locations such that groups of locations are related together as Tours, with Tours becoming first class citizens, and having their own table.
***
The standard Omeka product provides only one way to group Items - it is by Collection.
All of the issues that come up about viewing Items by Collection will also exist when you provide viewing Artist from Art Item, and Art Items by Artist. Figure that years of effort have not produced a standard universal solution to many of the issues for viewing Items in a Collection. Your customization will need to select and implement a way to navigate around the art that is grouped by artist, and to navigate around the artists.
Example:
- How to surface the set of Artists for visitors to browse.
- How to manage the order of Artists in the display list of Artists.
- How to show examples of art for a given Artist in Artist list.
- How to manage the order of Art Items in the displayed list of Art for an Artist.
- How to show the complete list of art for a given artist - one page or many?
- How to manage navigation and display if an artist's art list is shown on multiple pages.
- How to provide other forms of grouping art items for navigation that is different than by Artist.
***
You are showing some concern about the look of the URL and the item id. These are things that the standard Omeka product and most Omeka users do not worry about. These aspects should be a concern. They are connected to making navigation easy to understand, and to optimizing SEO.
It seems like you have an external "Artist ID" metadata value for each artists and use it to identify the Art Item's Artist. The Omeka "item id" is the synthetic unique database key value of the item, which is not a natural attribute of the item and is thus not stable. Delete an item and insert it again, and the item id will change.
For your situation, having a stable "Artist ID" outside of Omeka, you should continue using that and not depend on the Omeka "item id" for identifying a particular artist. This is a very technical area, with specific best practice based on the specific situation. The general answer is to avoid using the synthetic unique key value for anything public facing, including the URL. Unfortunately, Omeka's standard URL uses that synthetic key value in the Show Item URL. This can be changed by use of the CleanURL plugin.
Bob
rs-remove-suffix@speray-remove-suffix.com