Page 1 of 1

Extend documentation typology and manage physical folders...

PostPosted:Thu Aug 25, 2011 9:17 am
by gelinp
Hi,

It looks information management by OpenKM is too much technical. What I mean is that end user need to manage information at documentation level. I.e. I need to type documents with specific documentation vocabulary. At this time OpenKM display 3 documents types into reserch interface : Document, folder, mail. What End user need is to create more documentation type as thesis, report, draft (may be a property of 2nd level to each other document's type), bibliography, manuel, catalog, etc... This specific documentation typologie level help very much to manage document as list against hierarchy systems. By the way, it will allow to add specific physical paper management. Indeed, if you image a paper type, you can inculde specific fields into this metadata to manage physical location into racks... This is a very important and urgent new feature : manage physical papers. I would like to emphisize that it's not always possible to scan all papers, and it's not the same way to manage automatically scans or to manage manually papers. Personnaly, I can't use only electronic document and I need to manage physical folders and papers.

Thank you for OpenKM team.

Re: Extend documentation typology and manage physical folder

PostPosted:Fri Aug 26, 2011 2:04 pm
by jllort
we've got on mind implementing record management, that will be able to configure this kind of information you need, it'll be available at new release ( upper than 5.1.x ). About phisical folders, I don't understand exactly what you've got in mind ... could you explain with some example ?

Re: Extend documentation typology and manage physical folder

PostPosted:Sat Aug 27, 2011 6:00 pm
by gelinp
yes. The problem is that I've got a lot of paper into folder (paperboard). So, like Records Managment I need to organise this information and use openkm to look for information and navigate trhough this folder and papers. Records Management is not only the ability to manage paper and electronic files, but also to manage life cycle of information. What you could add in a first time is only a document's type to manage paper document. The only difference is that for electronic doc you upload the document into openkm database, and for paper document we need to manage a physical address (alphatical, time, conceptual or ideological file plan). By the way open will implement an electronic numbering machine, in order to put a unic number into the paper doc in order to identify exactly papers into the openkm database. Thius number need to be printed (manual writing) into the document. Without speaking life cycle management this is, I think, a first step to help people to manage paper documentation.

Patrick

Re: Extend documentation typology and manage physical folder

PostPosted:Tue Aug 30, 2011 6:47 am
by jllort
That will be solved on next version with record management.

Re: Extend documentation typology and manage physical folder

PostPosted:Fri Sep 02, 2011 5:54 pm
by gelinp
Do you mean the really closed next major version ? Could you please give us a roadmap and a "dead" line ?

Patrick

Re: Extend documentation typology and manage physical folder

PostPosted:Tue Sep 06, 2011 6:45 am
by pavila
Will be released when ready :)

Re: Extend documentation typology and manage physical folder

PostPosted:Sat Sep 10, 2011 1:55 pm
by gelinp
ok, but please give a roadmap idea, I need it ! :( Byt he way way could you explain a little features to manage paper doc. In fact, you need only a new metadata field to add specific paper cotation, in order to look for the parper into cabinets ! It's a minimum but it's enough. OPenKM also have to accept a new doc type, without obligation to add numeric path or a link...

Re: Extend documentation typology and manage physical folder

PostPosted:Tue Sep 13, 2011 6:32 am
by jllort
New major release is scheduled between ends December / January.

I don't understand what do you want to do with metadata, now you can define your own metadata groups, the problem is that you must register under folder or document ( that's why is need new object to store other kind of registers ).