Best practices on categorization

Hello Folks,

When it comes about categorization, what is the best practices that most of Plone sites are using today?

For example, if I have a list of objects with Categories and Sub-Categories, I imagine that OOTB we can separate Categories with one level of Folders, and Sub-Categories with Sub-Folders? or TAGs field is more used today?

Another possibility would be collective.taxonomy addon, but I can't make it works with last version of Python and Plone, got some exceptions 1, 2

So, can you please share with me how you usually solve this?

A folderish approach is unlikely the right way. In many cases things fall into different categories and duplicating content is unlikely the right way. In various context (e.g. medical content) we organize I content flat or according to some logic in simple folders. Categories or subcategories are maintained as metadata.

2 Likes

There is no ready recipe, you need to analyze the characteristics of your content. We work a lot around here with newspapers and magazines, where texts are usually part of sections. In this context, we created collective.NITF which has a specific field for sections and other metadata related to news items.

Folder separation says more about navigation than about categorization. I think it only makes sense to use folders as categories to simplify development and when navigation and categorization are very similar.

2 Likes

So to sum up OOTB we can't do it in a proper way?
If I understand correctly everyone use own customization recipe to fix this problem.

How about to create new fields in Plone core to do categorization in a proper way?

If we follow what c.taxonomy does, we should add a new configlet to add categories and sub categories and a new field in all objects at categorization tab to select the category.

Am I missing something?

As @agnogueira wrote: you need to analyze and define your requirements regarding categorization first and then decide which approach to take.

How to create new fields in Plone? Either write your own content types or write a custom behavior containing everything that would be necessary to implement your supplementary metadata.

1 Like

@zopyx I understand, but what I'm looking for is to enhance Plone, and have one generic option to add Categories and Sub-Categories OOTB with Plone.

I have experience writing customization's and behaviors, the objective here is to bring something useful to the Plone comunity.

It sounds like you want to write a PLIP for integrating collective.taxonomy, or parts of it, in Plone core. Sounds good to me. Next the framework team will give you feedback about it and you can act upon it.

Try to search for similar PLIPs before, I'd imagine this has been proposed this before.

1 Like

We don't need this in the Plone core since the requirement is not requirement which is needed by the majority of Plone users. Better work on the module for bringing into shape and making it compatible with Python 3 and Plone 5.2, Plone 6 if needed.

2 Likes

Regarding your issues with c.taxonmy: try out the latest code from Github...perhaps some issues have been fixed on master..Otherwise, write a bug report or try to fix the issues yourself. That's how it works.

1 Like

Well, others CMS have it OOTB, so I see that would not hurt to also have this functionality.

It can be added as a behavior that you can enable or disable as you wish.

https://www.drupal.org/node/120624

Maybe add c.taxonomy in the core would be a great move!

An important point is that since community is small there's a general orientation for keeping Plone core/OOTB as minimal as possible considering "it's so easy to install a plugin".

In fact it is but also a "Plone specific knowledge". I'd be +1 making the OOTB taxonomy story stronger because it's closely tied to the content managing experience - even if behind a control panel setting (likely disabled by default). I believe it'd be a low-maintenance and low-hanging fruit which would help in side-by-side comparisons.

See:

2 Likes

I can reproduce the same error (among) others with the current master branch..likely the code needs a bit of love for Python 3/Plone 5.2

1 Like

Plone has the folder dimension OOTB, so in many cases you can use folders like categories in a simple way. If your case need more than that (like content in more than one category), you may need to develp or use a addon.

Sometimes a killer feature dont need tho be in plone core, but in a great addon. Remember some very used addons, like forms, cover, social...

Im not sure about this feature in core. Using Category and Folders together always cause confusion in users. And sometimes causes a work duplicity, when the user needs to create a new category and a new folder to represent the categories in navigation.

1 Like

Hello @rodfersou, sorry for responding so late in the game/thread. We developed collective.classifiers 6 years ago for the main site of the Flemish environment agency to hit the sweet spot between a full taxonomy with unlimited depth (collective.taxonomy) and adding a too simple controlled vocabulary field with index.

The README of collective.classifiers explains the original use case well enough.

Recently we had a requirement for categorisation in a running project with Plone 5.2, I've done the minimal to get it working but still have to fix travis and some other stuff (https://github.com/collective/collective.classifiers/tree/plone5). Main problem is that editing dicts is broken at the moment in the resource registry in Plone 5.2.X and we use the registry to store each field as a dict containing tuples to provide 2 levels.

As others have responded, adding/configuring/implementing categorisation is information architecture and depends a lot on the information.

Collective.classifiers was set up as a behavior with 2 fully identical fields, but we labelled them 'theme' and 'category' to fit the contents of the site. There was a 'thematic classification' with main and sub theme's for the different working area's of the government department. But there was also a 'category component.

The 'cross' of setting these two fields yields an overal relational labelling system that lies on top of the default folderish/item hierarchy which Plone provides, independent of content type. So for example you could create a Page and label it with theme: 'water -> pollution' and ' category: 'law' . On the landing page of the water pollution theme (which was/is a collective.cover) we have a search tile that lists all recent law documents on water pollution'. (or news, or 'tips and tricks as categories)

One of the main reasons we developped collective.classifiers was that the original 'functional' design creatd by a Drupal-focussed UX agency (we'll do function design plans, but write it for the CMS system we now Well thank you, this is an implementation document). In this design they listed 20-25 content types, because each category had to be its own content type. Which is a bit silly in Plone, because you would have to maintain 20 custom CT's with almost no difference in functionality. Now all content is either a page, news item, collection, or cover and with the theme x category labelling on top we have a few CT's but a lot of flexibility.

So with this new project, I need a third classification 'angle', but it's a geographical/location based taxonomy. And my 'fixed' field names are theme and category. Bummer.

One of my pet peeves with Dexterity behaviors is that I'd love to have the behavior configurable with parameters and have the field titles/descrptions configurable using these. With that possible I'd strip collective.classifiers down to one parameterizable behavior with configurable field/description names and add 1,2 of 3 of these behaviors with the correct semantic labels. I do realise the complexity under the hood for indexes, catalog brains/metadata when the field names are not hard coded anymore, but still.

One workaround we use at the moment to make one generic behavior more specific in a site, is to abuse translations to overwrite the field names/descriptions, we use that trick in another behavior (https://pypi.org/project/collective.behavior.altimage/) where the 'altimage' field name gets the correct name in the site itself. You can add translations for English as well. :wink:

Hope this helps.

1 Like

If your 'leading' taxonomy is very strong with the top down ordering, you can use the hierarchy as a taxonomy dimension. The challenge with any container/contained hiararchy is that you have to pick a top down ordering and you cannot 'flip' the nesting easily to get a different ordering.

What I mean is : if you have "car brand" -> "car color" -> (car model/item) . You can only find the same colored cars within one brand, but you cannot navigate to the folder with all red cars from every brand. You have to add extra classification.

If you use plain folders for the content hierarchy, your editors and site vistors 'know' that this folder is also a category, but without extra config/development 'Plone' has no clue which folders (and their titles) in your site are a category and which folders aren't.

Then you either add a 'category' folder CT, or maybe develop a behavior, which 'categorizes' the folder (in a categorised folder hierarchy), builds an index and exposes the found categories in vocabularies to the querystring/collection functionality in Plone. IIRC there was a taxonomy add'on that did this, but I think it was Archetypes/schema-extender based, not dexterity.

Last but not least: every site as different requirements on who can edit what: can editors modify the taxonomy/classification by adding category folders? Do you want a managed/controlled or an organic taxonomy?

2 Likes

Why don't you use already exising tools such as https://iqvoc.net/ and just use their api to get/set?

Another option is to import the skos vocabulary in triplestore (for example Jena Fuseki) and query it via triples.

The the result is set/get from a dx string field.

2 Likes

@fredvd Thanks very much for your input!

Meanwhile I was working this week on collective.taxonomy with help of @petschki.
The current state of the package is very good, we fixed the problems, added more tests, lint the code and added cypress test.

By the way, cypress is awesome! you can see the test for taxonomy here:

And here is a movie of the test running:

Today my plan is to add some docs and cut a new release.
Regards!

1 Like

@yurj this is new for me! thanks for the input!

I'll consider some integration with this service in the future depending on the project requirements.

My use case now is quite simple, collective.taxonomy can do a lot more than I need actually.

Regards!

1 Like

The main benefit is to reuse classifications and thesaurus, especially when you've standard ones. In your case, collective.taxonomy is a great tool.

1 Like

Added a Getting Started Tutorial for collective.taxonomy: https://github.com/collective/collective.taxonomy/blob/master/docs/tutorial.md

Plone Foundation Code of Conduct