Open Source Document Management System | OpenKM

This a great thread:
Its great to know how to organize in Taxonomy, and i see the benefit of creating a series of subfolders based on each digit. Basically, from what I see, the repository does the same in the background, but does it every two digits.

Now, how about "categories" and subcategories? I guess we will have to do the same? otherwise supposing we have 1 million documents spread over 10 different categories (or document types), then browsing through the 'categories' section, each category will end up with 100,000 documents, which is not good according to the messages in this thread.
Breaking down categories into single digits folder (like done in taxonomy) will take so much time!!

Any advice / best practices on this issue?
Thank you all.

In the scenario you are proposing 1 milion docs, my suggestion is do not using keywords, categories etc... and think in metadata and search feature. Really users should not navigate across the repository, should looking for documents across the search engine, what provides a quick response and from that view get documents. Basically taxonomy is a way for well ordered data, but when you want to accessing should think on metadata. The idea is, for each document, how my users will try to find it ( for which fields ) -> you must create a table ( excel ) for each type of document indicating the fields and what is needed for finding it ( is possible for finding will be needed extra fields ).

For example and invoice:
status -> payed or not
client -> list of clients or client code
date
observations
total
vat

here you have a good starting point for metada fields definition http://wiki.openkm.com/index.php/Proper ... nistration

thank you for your advice jllort.
I did look into the details of how metadata work.
I am still trying to grasp the way this UI works.

But from what I see in the UI "taxonomy", "category", "metadata", all show in the same format. So, what applies to "taxonomy" (meaning how it should be structured), should apply to the other two "category", "metadata". Am I misunderstanding something here? advice?

A post above said "Good practice is get 100 nodes per parent ( at least 500-1000 ) but take in mind icreasin the number of nodes per parent the performance will decrease ( basically the problem is on UI, large tables needs more time to render all information."

I guess this means that a folder should not contain more than 100 subfolders or files, and this advice should be applicable to all three "taxonomy", "category", "metadata" at the UI level.

Concerning to the example above:
invoice:
status -> payed or not
client -> list of clients or client code
date
observations
total
vat

It's possible to have ten of thousands of Invoices with "status" = paid, and looking at these in the UI through the metadata panel will display them all i.e. tens of thousands... this is against the best practice stated above.

What I am not understanding is how these two UI panels ("category", "metadata") should be structured to show few records. I do understand these help in the search panel by filtering records, but I do not understand how they work from the UI aspect. Or may be these panels are meant to display to the user what levels exist, but these panels should not be used to browse records using them? is that it?

Can anyone provide an example of these two panels "category", "metadata", and if they can be used to browse records?

Thank you.

Because you are thinking on browsing and it's a bad way for looking for a document etc... I suggest use metadata rather keywords and categories. But obviously althought you can navigate across metadata it only have sense if you have small repository, otherwise keep out of mind to use this feature. What you really should be thinking is on using search view. This is the right place for looking for information quickly. Doing searches based on metadata and retrieving results in few seconds. This is the correct way, from our point of view how the application should be used. The taxonomy keep you getting the data organized ( like real archive ) and search engine provide to you a fast indexing (shortcut) for arriving at the information.

For huge repositories this is the right scenario. Structured data into taxonomy and quirk links across search engine to arrive there. Forget categories and metadata browsing and keywords, but use metadata fields for searching.

This makes a lot of sense... thnx Jllort.