Taxonomies for content items

Feature Concepts
1

This feature proposal covers a lot of feature requests, coming from you in the support forum but also from Enterprise customers.

For example:

I am talking about Taxonomies

What is a taxonomy?

As a developer I have never used this term before but I have found several other products and competitors which use this term, so it seems to be a common concept in the field of data and content modelling. It basically the classification of things, that is typically defined in a hierarchical way, for example:

Here are examples of their usage:

  • Content releases: Group your content items as they are to be published in upcoming releases.
  • Projects: Organize content in projects and subprojects.
  • Business-specific categories: Product categories, colors, localities.
  • Website hierarchy: Use taxonomy to represent your website hierarchy and assign content items to their locations in the hierarchy.

Especially the last hierarchy is often used in web development.

Do we really need it?

This is a difficult answer, I would say yes and no:

No, because…

  • We can already model taxonomies and parent child relationships with references.
  • We can already model simple taxonomies like colors with tags and “allowed-values”.

Yes, because…

  • References do not model any hierarchical relationship and restriction.
  • Some features cannot be implemented when the hierarchy is not know, for example a reference selector that works like a wizard, where you first select the continent, then the country, then the city and so on.

Requirements

For now I will formulate this very basic requirements:

  1. Define unlimited number of taxonomies per app.
  2. Taxonomies can be defined with a schema hierarchy or constant values.
  3. Products can be part of multiple taxonomies.

How to define taxonomies?

Taxonomies have a name and are defined in a tree like structure, e.g. level can be either a schema or a constant value.

When we have an example like localities we can use a mixed value where we just use constant names for the continents and then we define that a you can attach countries to continents and cities to countries. This reduces the number of schemas and content items, especially when we only need them as categories or to be referenced by other items. But can be problematic when you need to convert a constant name to a content item.

In other examples like product categories, we are probably fine a with a set of discrete values, for example

  • Colors (red, green, blue, white, black…)
  • Sizes (S, M, L, XL…).

Taxonomy%20Definition
Taxonomy Definition.png810×728 33.8 KB

How to work with taxonomies

You basically get a sidebar with the taxonomies, where you can switch between taxonomies and assign content items with drag and drop:

Taxonomy%20Usage
Taxonomy Usage.png1649×728 40 KB

2 Likes
2
3
4

Hi @Sebastian, superb support from you as always! Thanks for this proposal from which we can all benefit.

Can you elaborate a little bit on how this sidebar is being added? Is this an addition or does it replace existing functionality (probably not)? Thanks your providing the wireframes. I’m not really sure if I understand the left part (with content) of the last image correctly.

I think I’ve understood what you define as taxonomy and how the UI will look like for creating one. Would you mind adding 1-2 more examples (and screenshots / wireframes) for how we can use them? This would give me a better basis for constructive feedback :wink: Thanks!

5

In the second mockup you can see the normal content list on the left and on the right side the sidebar with taxonomies.

1 Like
6

Ah okay, great! Then please go ahead with the implementation :wink:

7

Hi @Matthias

I wanted to start with it, but I have a few doubts right now, because we would create a second system for references. What is your use case?

If we are talking about simple “taxonomies” like colors or shoe sizes we could implement something simpler.

8

Hi @Sebastian,

thanks for addressing this feature concept again.

Technically, you are right since a tree view or a taxonomy with multiple hierarchy levels is the same as using references. The difference is the how these hierarchies are visualized to admins and customers. With an arbitrary taxonomy systems, we can define how to group / show content to other users.

Define unlimited number of taxonomies per app.

I really like this approach. I know I’ve been nagging you multiple times about a tree view structure for “pages”. This would finally make it possible. I’m still not sure where I would show my “data objects” (see the screenshot I posted in my original thread) but I would use taxonomies for them as well.

9

For example I think that the concept of taxonomy terms that are just strings does not make sense.

Lets think about E-Commerce, where your taxonomies are colors or sizes. When you need your terms for other things, for example to implement a filter, you need more than just a string, for example translations, rgb color and so on. Then we have schemas again

When we have no more terms than we just have contents and references that are modeled in another way.

Therefore the question is for me, if we just need another visualization for references. We could also build a view where you see content items and their references items. The only question is: How to select the root? Because technically it does not exist…

10

@Sebastian We definetly need a root since there is no default one. It doesn’t make sense to show every content item without an incoming edge (if you see references as a graph) as being displayed under a virtual root.

I’d say it makes for sense to select one content as a root and show all referenced items (and their sub items, and so on) in a tree structure. You could place a drop down in some general settings where you can select a single (or more than one to allow for multiple roots) content as root.

I think one thing might be missing though: Sometimes it makes sense to add ‘virtual’ hierarchy levels to further divide content into groups where such virtual levels to not exists on their own (so they don’t have schema. They just exist as another hierarchy level). I’m not sure how to model them correctly. Maybe we need to have them as schemas as well (so they support references out of the box) but I’d like to have the option to filter them out from the standard schema list. If I, for instance, have ~20 ‘virtual’ schemas that only serve for making a nested hierarchy (as a tree view), I don’t want them to pollute my normal schema list. Maybe we can have a checkbox that says ‘show all schemas’ and for each schema we could have a ‘hide from schema list per default’ checkbox?

11

Hi Sebastian,

Would that mean for graphql queries will be able to access all schemas at once with one app endpoint?
It would basically solves [this somewhat convoluted integration] (https://www.jamesbaum.co.uk/blether/integrate-gatsby-cms-join-graphql-queries/) with Gatsby, for example?

As a side note, I have to add that the quality of squidex as CMS (code and user experience) really stands out from the crowd, keep up the great work!

12

Thank you for your nice words.

I would say it is not so related to GraphQL. But right now you can already include asset that are referenced from content items.

For authors there is no solution yet, but you can create another feature request.

Regardless of taxonomies our goal should be to get all needed data in one request.

13

I was thinking about the fact that, for example, Odata filters in graphql can’t traverse references (is there already a feature request about this ?)

14

I have a similar need to have all of the nested reference data populated in one REST api request as well. From the integration standpoint, we have a header already that will populate asset fields with their URL equivalent, is there anything stopping us from having another header that would populate nested references?

15

This is what GraphQL is for. I think it does not make that much sense to extend the REST endpoint further.

16

I’m really interested in this functionality and I like the idea of having a taxonomy of schemas based on the hierarchy of the content.

On the other hand, I feel like reference fields get me almost all of the way to what I personally need.

All I really need is a way to make the selection box in the UI for a reference field be displayed like a tree for references of references.

To be clear:

I want to have a schema for “categories” which is basically just two fields, a name and a reference which references back to the categories schema. I also would have a schema for “pages” which is for all content on my site with many different fields, but one additional field being a reference to categories.

Since the categories reference each other, I want to display this in a tree view for content editors to make it easier to identify where on the site the content is being placed. Sub-categories might be similarly named to others so it’s important to distinguish them.

I don’t see a way to achieve this today, but perhaps I’ve overlooked something in the documentation.

1 Like
17
18

Just checking back on this since it has been about a year since my previous post. Has work on this feature idea been abandoned or is anything planned?

19

I have talked with some enterprise customers that also requested this feature and nobody could really tell me what they need. So as long as this is unclear the feature is on hold.

20

I’ve been away from this project for a few years but recently had something come up where it might make sense to use it, but wondering if anything has changed around this hierarchy type of concept? I was looking through the change log on the site, but it doesn’t go back far enough to see what may have changed here. It looks like the new components feature might solve part of what I was looking for, but curious if anything else has been implemented.