Good practice use case

[ralfh]

I would like to get feedback for the following scenario by experienced users.

I’m preparing next week a draft version for a local heritage museum and archive here in Berlin. Its an NGO in northeast of Berlin where 400.000 residents live. It was part of GDR before reunion of Germanies. The NGO has only 50 members and only 20 are active, most of them elder than 70 years.
They create 1-2 historical exhibitions/year, publish 3-4 times/year a magazin (more than 1.000 articles up to now) and organize 3-4 monthly onsite events.
The archive is not well organized and we try to work on it since last year.

My idea for a tainacan structure:

Multiple collections

• Images: postcards, fotos, (1.000-2.000)
• Exhibition posters
• Maps (100)
• Artwork (50)
• Printed: books, articles, brochures, handwritten docs, certificates, etc. (3.000)
• Multimedia: videos, audio, interviews

1 common taxonomy

Here are some cases and scenarios I would like to tell within Tainacan

Case 1: Blacksmith
Paul got permission to build a blacksmith in street A, John was his successor, a few years later the blacksmith was burnt down by a fire and a new one was built by John in street B. None of the buildings exist anymore.
Research question by users: What was the history of blacksmith? I’m standing in front of the actual building and I am interested what happend here 200 years ago.

Case 2: Street names and numbering system
The museum has hundreds of fotos from streets and buildings, including postcards documenting how it changed over time
The name of he street changed several times. The numbering system changed also without changing the name of the street. The same house was KW-Street 23, later: KW Street 53 and today D-Street 53.
Question for the taxonomy: How can I structure the taxonomy that I can search for fotos of one specific building? What is a good structure for parent/child model?

Case 3: Schools
In the beginning there was a smal primary school with 2 classes. Later they moved with 4-6 classes in an other building and after a few years they rented additional rooms in other streets (one school but different locations at the same time). A college was founded for boys only. Later a college for girls was founded as a seperate school. The boys school moved into the former city hall, the girls school moved into a seperate building near the boys college. After WWII both schools merged into one school. The former girls college was used as a vocational school. The name of the schools changed several times.
Research questions: how can i structure the taxonomy that it tells the story and the different schools are connected in some way?

I know that no taxonomy is perfect for all situations and for ever. But I will try to avoid any grounding mistakes from beginning.

[andre_benedito]

I found this use of Tainacan and the type of problem you are trying to solve very interesting. It is a very rich scenario, especially because it involves changes over time and multiple layers of information.

I will try to contribute with some modeling ideas based on the cases you presented.

Regarding Case 1 (blacksmith), before thinking about the modeling itself, there is an important conceptual question that is not yet clear: what exactly is the entity you want to represent in Tainacan?

Based on your example, there are at least two distinct modeling possibilities, and each leads to a different structure:

The building (physical structure)
You could treat each blacksmith shop as an item (or more than one item, if there were reconstructions). In this case, you would be modeling “historical places”. This would allow you, for example, to associate geographic coordinates and connect the item to a current physical location (where the visitor is). The historical narrative (construction, fire, reconstruction, change of address) could be contained within this item or represented through relationships between items.

The people (Paul, John)
If the focus is on historical agents, you could structure the items around people, and the blacksmith shop would be an attribute or a relationship (for example: “place of activity”, “occupation”, “time period”). In this case, the history of the blacksmith emerges from the relationships between people, places, and events.

The key point is that, in Tainacan, each item needs to represent a clearly defined entity. In your current scenario, this is not yet explicit.

In addition, your question (“I am standing in front of the current building, what existed here 200 years ago?”) suggests an important element: spatial anchoring in the present.

To support this type of use, it is generally necessary to:

• associate geographic coordinates with items
• or create a specific entity for “places” (even if the original building no longer exists)
• or maintain a layer of “historical addresses” that can be related to each other over time

You could also use a QR code linking to the Tainacan item that represents and tells the history of that place.

Now, regarding Case 2, I believe we could borrow the museological idea of having a “main” registration number for the item and other numbers that would represent historical numbers. In this approach, I would always treat the current number as the main identifier, and the other numbers would be associated with it as a metadata field called “other numbers”. These could also be called old numbers or historical numbers — the name of the metadata field can be defined later.

Another idea that comes to mind — but that would need to be checked with @mateus.m.luna — is when it will be possible to create filters for different levels of a taxonomy and assign different names to these filters. This would allow treating the first number as the parent taxonomy and the others as child taxonomies, solving the problem.

The issue with this approach is that, currently, we cannot have distinct filters for parent and child taxonomies. This could confuse users, because when opening the filter, it would not be clear that there is a parent term representing the main taxonomy and child terms representing the other numbers.

Case 3 is a bit more complex. Here again, it is necessary to think about what entity is being represented in Tainacan.

I also did not see any collection among the ones you suggested that would fully address this, and it does not seem to me that taxonomy alone would be able to tell this story — at least not adequately.

One possibility is to treat each physical structure as a Tainacan item and have one collection for these places (buildings, squares, etc.) and another collection for institutions, such as the “Primary School”, which occupied different physical locations over time.

From there, these structures could be connected through a relationship metadata field, creating a collection that represents institutions. In this case, you would have, for example, an item for the institution “Primary School”, where you could describe its historical changes and relate the different buildings as associated items.

A second possibility would be to represent this history through a static page in Tainacan. In this scenario, you would tell the story of the small primary school through a structured narrative and bring in items from different collections to support that story. In this case, the structuring axis shifts from the item to the page.

[mateus.m.luna]

I think this is the kind of discussion that is ideal to have at this stage, before modeling your collections and metadata. I would also invite @Danielle_do_Carmo, @Maria_Cecilia and @rodrigo_freire to take a look in case they have some ideas or tips.

For me it is a bit hard to get the entire concept but I can bring some more generic ideas.

1. Remember that what brings items together in a collection are the metadata that defines them. Sometimes things can be “separated via classification”, which is what Taxonomies do, but still belong in the same place and be qualified mostly by the same data, which is what collection metadata do. With Taxonomies you still have the 1. Taxonomy Term Items list, which mimics a bit of what a Collection offers, but still works as filtered vision of the data.
2. I said “mostly” because sometimes it is OK to mix a bit of data. A Collection can contain metadata sections that are conditional. If a certain metadata has a value A then new fields appear. If it has value B other fields appear. In the item page, if a value is not filled, it simply won’t appear. This is however limited to certain types of conditions so don’t overuse it. If the data is to heterogeneous, it is time to separate into new collections.
3. Relationships are powerful if you use features like “metadata displayed field” and “items related to this”. Most of the ideas proposed by André you can achieve with them. But remember they are also harder to maintain. As the data is in another place you won’t be able to easily import and export them or even filter in the same way because things are stored in another collection.
4. Hierarchical taxonomies are nice for visualization of that hierarchy in the item page but are not easy to manage if you want to give meaning for the leveling. The thing that @andre_benedito mentioned for example would only be possible if we have something like this or this.