Category hierarchy handling.

We tried to make OpenKM as intuitive as possible, but an advice is always welcome.
Forum rules
Please, before asking something see the documentation wiki or use the search feature of the forum. And remember we don't have a crystal ball or mental readers, so if you post about an issue tell us which OpenKM are you using and also the browser and operating system version. For more info read How to Report Bugs Effectively.
Post Reply
mountain73
Junior Boarder
Junior Boarder
Posts: 32
Joined: Thu Jan 29, 2015 8:44 am

Category hierarchy handling.

Post by mountain73 »

Hi all.

I entend to set up a complexe category tree. I proceed to some tests.
With category tree folder, I was expecting a subcategory to inheritate from its parent category as this is usually the case: example a gorilla is an item of monkey subcategory, which is a subcategory of primate, which is a sub category of mamal animal. By putting gorilla in "monkey" subcategory, I expect it to also have the categories "primate" and "mammal" animal automatically assigned.

This mechanism does not seem to be the case with openkm: I assigned a child category to a document, and category parent is not assigned to this document.
Is there any way to do so automatically? (option activation? script?).
Thanks for any help or tip about this subject

Regards

Mountain73

jllort
Moderator
Moderator
Posts: 11151
Joined: Fri Dec 21, 2007 11:23 am
Location: Sineu - ( Illes Balears ) - Spain
Contact:

Re: Category hierarchy handling.

Post by jllort »

Yes inherit has not been considered, in some cases will have sense,in other not. For doing something similar when each category is added, should be linked an event -> add category or remove category and then propagate in parent nodes. Categories are thought as atomic words ( SKOS ), other way to get it should be change the search engine. Take in mind is not good idea to set a lot of nodes in a single parent, when you're drawing 1000 elements on a table the performance begins poor. On a good taxonomy you should try to have 200 or less nodes per parent, with these numbers you will have the best UI performnace.

Anyway, I think you will get best success doing it with metadata. Try for example with a select:
gorila -> value 001 ( values should also be 001*, think like value is used as a string into the lucene search )
monkey -> value 0011

With this codification each time you will search for gorila, also will get all 001* codes

mountain73
Junior Boarder
Junior Boarder
Posts: 32
Joined: Thu Jan 29, 2015 8:44 am

Re: Category hierarchy handling.

Post by mountain73 »

Hi jllort.

We have rethink the category handling. In fact, as you said, the most appropriate would not be to inheritate category from parent category, but to have a search engine that could return results from child category. (To keep the same example, if I search for category= "primate" and name= "gori*", it should be able to return the item "gorilla" which is only is a child category of "primate".)

So as you said, it is more a "search engine" issue. I saw that in professional edition, the search engine is different from the community one. The category handling in pro search engine corresponds to the behaviour mentionned above. How difficult would it be to transpose it to community version?

This interests us a lot, but we are reluctent to move to "professional" version for two main reasons:
1- It is will be a non-free version. For the moment, the only feature that could motivate this version change is the search engine. I just sent a pricing demand in order to have an idea of extra cost.

2- We could not find a precise list of features differences (http://www.openkm.com/en/product/compar ... sions.html is too general and vague). Professional version does not seem to be just an upgrade with additional features: For example, I noticed that in community version (installed on our server), you can download a zip file of document belonging to a category, but in professional version (demo openkm site), you cannot.

Thanks again for your support.

Regards

Mountain73

jllort
Moderator
Moderator
Posts: 11151
Joined: Fri Dec 21, 2007 11:23 am
Location: Sineu - ( Illes Balears ) - Spain
Contact:

Re: Category hierarchy handling.

Post by jllort »

I will try to explain the difference between community version and professional one. Each year we do a major release from community to professional. The major release means we have some professional version branch and we share almost code, not all, but almost. Actually version 6.3 community correspondence is with 6.2 professional. We close the development of version 6.2 two years ago. The distance between 6.4 and 6.2 ( professional ) is about 3-4 years, because on the last years of a branch we only apply patches. Next year we will release version 7, what will be a major upgrade and will come with a lot differences. During next year we will do a new release based on 6.3 with new features still not presents on community edition and probably will be the end of these release. The way on how we are doing releases is the cause why some features will take some time to be shown in community edition. Take in mind we maintaining about 4 branches at same time, one for community and three for professional. To make our life better we decided do the community releases always on the direction I indicated before and that helps us on the general maintenance releasing well tested versions.

Post Reply