[alg] Document Management Systeem Structuur opzetten

[PhoneTech]

Ik probeer een document management systeem (DMS) op te zetten maar het tegenstrijdige requirements

Allereerst de requirements vanuit onze development partner:

• addFile(File file) returns fileGUID
• getFile(String GUID) returns file
• getFile(String GUID, int Version) returns file
• IPR protection (Intellectual Property Rights) object beveiliging op gebruiker en rol beheer.

Behoorlijk basic dus. Zij hebben alleen de get en set methoden nodig. De bestanden worden dus gelinked aan objecten in hun systeem dus hun systeem behoudt de structuur.
Probleem bij deze aanpak, is dat je met limitaties van een File systeem te doen hebt. Een folder kan maar max iets van 64k aan bestanden kwijt in linux geloof ik. Alles opslaan als blob is echter een big NONO .

In onze omgeving moet het ook mogelijk zijn om door de structuur te browser. Ons systeem bevat namelijk populatie scripts wat files importeerd vanuit een ander filesystem en in ons systeem importeerd.

Onze requirements boven op die van onze parter:

• Full Text Search
• Version Control System
• Browsen met webstart client
• Mogelijkheid bieden voor web interface

En daar zit nu juist het probleem. Ik wil dus een systeem opzetten waar de structuur van de data in document management zit, terwijl zij een systeem willen hebben met alleen de get en set dingen.
In ons systeem laten wij dus de gebruiker een structuur op zetten. Hier zit natuurlijk ook weer een enorm probleem, en dat is de menselijke factor. Ook zal er een toekomstige searchengine in moeten komen. Hier weet ik niet of je nu wat aan een structuur hebt.
Het uiteindelijke doel van de DMS is het compleet overnemen van de filesystemen die nu in gebruik zijn (samba shares enzo). Het systeem moet daar dus ook rekening mee houden.


Hoe moet ik de structuur nu opzetten.

Alles in 1 folder kan niet, omdat je dan met restricties zit.
Engineers de folders laten maken betekent meer werk voor de engineers wat ze niet willen (en ik hun ook neit wil laten doen).
Automatisch folders maken op basis van content is ook een optie..maar hoe

Met structuur bedoel ik de directories in DMS.
De andere development partner wil de structuur bij de DMS leggen -> nadeel: plat filesysteem (of 1 directory per object)
Ik wil de structuur deels bij de Engineer leggen -> nadeel: menselijke factor. Redundantie, oncontroleerbare folder en bestandsnamen.
Het liefst heb ik een tussen weg, maar geen idee hoe deze er uit moet komen zien.

[ Voor 22% gewijzigd door PhoneTech op 18-07-2005 16:22 ]

[alienfruit]

Waarom zou alles in een map moeten komen? De DMS kan dat toch mooi allemaal zoals managen? In principe zou het ook een xml database kunnen gooien, en dat de DMS dan die get() blabla laag er boven op heeft. Maar als ik het goed begrijp wil je niet dat de gebruiker via shares ding afhaalt, maar moet het allemaal via dit systeem.

Misschien zou je WebDAV kunnen overwegen, heeft meteen de web interface kant en Windows (webfolders) en Linux ondersteunen het ook. Volgens mij kan je vast wel in Windows zo opslot zeten dat de gebruiker alleen maar dingen kan benaderen via deze webfolders. Het leuke is dat WebDAV ook al een beveiligingslaag heeft, en o.a. via HTTP en SFTP werkt. Misschien nog te combineren met XMPP en de metadata.

[Alarmnummer]

alienfruit schreef op maandag 18 juli 2005 @ 17:43:
Waarom zou alles in een map moeten komen? De DMS kan dat toch mooi allemaal zoals managen? In principe zou het ook een xml database kunnen gooien, en dat de DMS dan die get() blabla laag er boven op heeft.

Waarom zou je het in een XML-Database willen stoppen? De documenten zijn geen XML dus een XML database lijkt me dan een behoorlijk slechte oplossing. Dito geld trouwens voor een db.

Zijn Subversion oplossing voor het documentbeheer lijkt me in ieder geval een goeie start. Verder denk ik dat de TS zijn vraag iets moet verduidelijken wat hij nu precies wil naast Subversion.

Trouwens in een hierarchische structuur van directories kun je maar een beperkte structuur aanbrengen (alleen een boom). Jij wilt eventueel ook netwerken aan kunnen leggen. Jij zult nu voor een mogelijke hierarchische structuur voor de informatie moeten kiezen, maar je kunt uiteraard door relaties te leggen tussen documenten, een volledig andere view(s) over het systeem aan brengen. Kijk maar eens naar zoiets als RDF: meestal zijn de web-documenten geplaatst in directories (op een server), maar door relaties te leggen tussen documenten kun je ook volledig andere verbanden visualiseren.

[ Voor 66% gewijzigd door Alarmnummer op 18-07-2005 17:54 ]

[Verwijderd]

Waarom niet automatisch folders maken op basis van filenaam of guid.

Je hebt je basis directory:

H:\DMSSTORE
En dan ga je gewoon verdelen, eerst op de 1e positie van filenaam/guid, daarna op de eerste XX.

dus:

h:\dmsstore\a\abc\abcdef.doc
h:\dmsstore\a\abe\abezyx.doc
h:\dmsstore\z\zxy\zxyqwerty.doc
...
...
...

die verdeling kan je zo fijn maken als je wilt, een goede analyse op de bestaande documenten moet je tot een redelijke verdeling kunnen wijzen.

Onderlinge relaties tussen documenten (en/of andere objecten/externe referenties) zou ik wel in een DB onderbrengen.

Wij hebben btw. een fatsoenlijk DMS systeem, incl. rechtenstructuur, odma, etc. (nu zelfs met integratie voor OpenOffice)

[PhoneTech]

Ik heb er eens even lekker mijn hersenen over gekraakt en ga denk ik het volgende doen.

SubVersion gebruiken om de bestanden in op te slaan. Ik heb overal gezocht naar het maximaal aantal bestanden maar nix gevonden dus ik hou het nu even op oneindig. Later kan nog altijd een soort automatisch folder systeem in elkaar gezet worden (naar idee van maui71)

De repository mag alleen door dms aangesproken worden. Filename hashen is dan ook geen probleem (om het moeilijker te maken voor kwaadwillenden)

dus plat subversion file system, met 32 String GUID als bestandsnaam.

Structuur dynamish laten opbouwen aan de hand van de structuur die in mijn systeem staan. Daar kunnen alle objecten namelijk n-m met elkaar verbonden worden. Ik denk zelfs dat een webDav interface naar de database ipv subversion ook goed te doen is.

[alienfruit]

Waarom zou je het in een XML-Database willen stoppen? De documenten zijn geen XML dus een XML database lijkt me dan een behoorlijk slechte oplossing. Dito geld trouwens voor een db.

Het was toch ook alleen een suggestie? Verder staat er toch ook nergens wat voor documenten hij wil beheren? Office bestanden kunnen prima in XML worden opgeslagen. Verder kan je ook XMP informatie aan de bestanden hangen. Het ligt er ook helemaal aan hoe je de informatie stroom in het bedrijf wilt gaan reguleren/beheren, je zou namelijk ook prima DMS/CMS kunnen combineren. Zodat als pietje de standaard waarschuwingen in de handleiding X wijzigt dat het automagisch ook veranderen in Y,Z en ook pagina Q op de website allemaal in één keer. Een document zou je vervolgens ook automatische kunnen laten generen op basis van een sjabloon en stukje data zoals een paragraaf of zelfs één zin. Content reuse. Heerlijk.

Vaak is het idee van zowel een DMS en CMS om inzicht te krijgen in wat voor informatie er nou eigenlijk aanwezig in het bedrijf. Als bedrijf wil je namelijk niet dat Pietje en Klaas Vaak allebei bezig met hetzelfde, omdat ze van elkaar niet weten dat de andere het al eens heeft gemaakt. Natuurlijk is een goed zoeksystem en de metadata dan ook erg belangrijk.

[ Voor 81% gewijzigd door alienfruit op 18-07-2005 19:50 ]

[Alarmnummer]

PhoneTech schreef op maandag 18 juli 2005 @ 19:30:
Ik heb er eens even lekker mijn hersenen over gekraakt en ga denk ik het volgende doen.

SubVersion gebruiken om de bestanden in op te slaan. Ik heb overal gezocht naar het maximaal aantal bestanden maar nix gevonden dus ik hou het nu even op oneindig. Later kan nog altijd een soort automatisch folder systeem in elkaar gezet worden (naar idee van maui71)

De repository mag alleen door dms aangesproken worden. Filename hashen is dan ook geen probleem (om het moeilijker te maken voor kwaadwillenden)

Hashen is geen correct coderingstechniek. De slechte maar wel goed werkende hash zou een constante zijn. Je kunt dus op 1 hash meerdere documenten terug vinden. En verder zou ik de security niet van dit soort geneuzel laten afhangen maar kijken wat je allemaal aantreft bij bv subversion.

Structuur dynamish laten opbouwen aan de hand van de structuur die in mijn systeem staan. Daar kunnen alle objecten namelijk n-m met elkaar verbonden worden. Ik denk zelfs dat een webDav interface naar de database ipv subversion ook goed te doen is.

Ik denk niet dat je de structuur van je gegevens op kunt bouwen op basis van de relaties. Relaties vormen altijd wel een netwerk terwijl jij alleen een tree aan kunt in het filesysteem. Als je bedenkt dat de filestructuur een van de mogelijke indelingsvormen is van je systeem, kan je nagaan dat je ook niet alle relaties kunt modeleren op basis van deze structuur. Ik zou me in ieder geval niet zo druk maken om een mogelijke hierarchische structuur maar eerder over de relaties tussen documenten en hoe je hier zinnige uitspraken wilt doen. Subversion is in dat op zicht maar een storage-detail.

[PhoneTech]

alienfruit schreef op maandag 18 juli 2005 @ 19:34:
[........]

Vaak is het idee van zowel een DMS en CMS om inzicht te krijgen in wat voor informatie er nou eigenlijk aanwezig in het bedrijf. Als bedrijf wil je namelijk niet dat Pietje en Klaas Vaak allebei bezig met hetzelfde, omdat ze van elkaar niet weten dat de andere het al eens heeft gemaakt. Natuurlijk is een goed zoeksystem en de metadata dan ook erg belangrijk.

De soorten bestanden zijn enorm verschillend. Veel SEM images (gewoon JPG) met meta data, Excel sheets, run cards, Word documenten, PDF en dat soort dingen.
Zoeken gaan we misschien inkopen...

Alarmnummer schreef op maandag 18 juli 2005 @ 19:38:
[...]

Hashen is geen correct coderingstechniek. De slechte maar wel goed werkende hash zou een constante zijn. Je kunt dus op 1 hash meerdere documenten terug vinden. En verder zou ik de security niet van dit soort geneuzel laten afhangen maar kijken wat je allemaal aantreft bij bv subversion.

Wat ik bedoel met hashen is een GUID. Niet op inhoud van het bestand dus.
[...]

Ik denk niet dat je de structuur van je gegevens op kunt bouwen op basis van de relaties. Relaties vormen altijd wel een netwerk terwijl jij alleen een tree aan kunt in het filesysteem. Als je bedenkt dat de filestructuur een van de mogelijke indelingsvormen is van je systeem, kan je nagaan dat je ook niet alle relaties kunt modeleren op basis van deze structuur. Ik zou me in ieder geval niet zo druk maken om een mogelijke hierarchische structuur maar eerder over de relaties tussen documenten en hoe je hier zinnige uitspraken wilt doen. Subversion is in dat op zicht maar een storage-detail.

De data die we hebben is niet hierarchisch. Er zit wel een beetje hierarchie in, maar dat is een detail. Opzich is alles n-m. Ook documenten. Relaties tussen documenten worden op inhoud gemaakt. webDAV is dan wel relaxed omdat je het zelfde bestand op meerdere plaatsen voor kan laten komen.

[Alarmnummer]

PhoneTech schreef op maandag 18 juli 2005 @ 20:19:
[...]
De data die we hebben is niet hierarchisch. Er zit wel een beetje hierarchie in, maar dat is een detail. Opzich is alles n-m. Ook documenten. Relaties tussen documenten worden op inhoud gemaakt. webDAV is dan wel relaxed omdat je het zelfde bestand op meerdere plaatsen voor kan laten komen.

Tja.. ik zou het netwerk niet direct proberen te simuleren zoals je het met webdav kunt doen. De query mogelijkheden van dat soort systemen lijkt me eerlijk beperkt als je allerlei algemene uitspraken wilt kunnen doen. Ik zou persoonlijk gaan (maar ik heb ook wel wat ervaring met dit soort dingen) gaan voor een semantisch netwerk waar je gewoon de mogelijkheid hebt om queries uit te voeren (bv eigenschappen aantonen). Semantisch netwerk kan je trouwens heel strak laten evalueren binnen een declaratieve taal (zoals in Prolog).. er zijn ook java implementaties van Prolog (heb er zelf ook een paar geschreven) waar je dit perfect kunt doen. En uiteraard kan dit geheel ook nog een prachtig gecombineerd worden met normale zoektechnieken (bv Lucene).

Maarja.. dat ben ik en dat is mijn kijk erop. Mensen die minder thuis zijn in deze problematiek zou ik dit niet allemaal aan willen doen

[ Voor 5% gewijzigd door Alarmnummer op 18-07-2005 20:35 ]

[djc]

Je kan Subversion 1.2 in ieder geval gebruiken via een DAV share met Autoversioning. Dat werkt gewoon transparant, je opent een bestand vanaf de network share, kunt het editten, en zodra je het opslaat wordt (een diff met) de nieuwe versie weer opgeslagen op de server. Lijkt me een keurige oplossing. Laat je de klant lekker zelf bestandsnamen bedenken directorystructuren...

[PhoneTech]

Manuzhai schreef op maandag 18 juli 2005 @ 20:56:
Je kan Subversion 1.2 in ieder geval gebruiken via een DAV share met Autoversioning. Dat werkt gewoon transparant, je opent een bestand vanaf de network share, kunt het editten, en zodra je het opslaat wordt (een diff met) de nieuwe versie weer opgeslagen op de server. Lijkt me een keurige oplossing. Laat je de klant lekker zelf bestandsnamen bedenken directorystructuren...

Helaas werkt dat niet. Beveiliging is namelijk nogal een grote issue. En we willen geen file system of subversion beveiliging gebruiken, maar van onze eigen protocol. Daarom is het direct benaderen van subversion uit den boze.

Structuur en bestandsnamen aan engineers overlaten is helaas ook niet mogelijk omdat het systeem zich automatisch vult.

[Alarmnummer]

PhoneTech schreef op maandag 18 juli 2005 @ 21:16:
[...]
Helaas werkt dat niet. Beveiliging is namelijk nogal een grote issue.

Je hoeft iemand direct toegang te geven tot subversion en met ssh zou je de verbinding kunnen versleutelen. Als je er dan nog een goeie netwekbeheerder bij neemt dan moet het imho wel vrij onmogelijk zijn om op een andere manier het systeem binnen te komen. Verder kan je java app dan direct met subversion praten om files erin te plakken.

[Verwijderd]

PhoneTech schreef op maandag 18 juli 2005 @ 20:19:
[...]
Zoeken gaan we misschien inkopen...

Tips:
- dtSearch
- Verity

[zneek]

PhoneTech schreef op maandag 18 juli 2005 @ 20:19:
[...]
Zoeken gaan we misschien inkopen...

[schaamteloze plug]
Laten wij (het bedrijf waar Alarmnummer en ik werken) nou net een zoekproduct leveren, met alle nifty features en technieken die Alarmnummer al eerder in deze thread beschreef
[/schaamteloze plug]

[ Voor 13% gewijzigd door zneek op 18-07-2005 23:37 ]

[PhoneTech]

zneek schreef op maandag 18 juli 2005 @ 23:37:
[...]


[schaamteloze plug]
Laten wij (het bedrijf waar Alarmnummer en ik werken) nou net een zoekproduct leveren, met alle nifty features en technieken die Alarmnummer al eerder in deze thread beschreef
[/schaamteloze plug]

[schaamteloze reactie]
Die opmerking was ook behoorlijk jullie kant op
[/schaamteloze reactie]

[djc]

PhoneTech schreef op maandag 18 juli 2005 @ 21:16:
Helaas werkt dat niet. Beveiliging is namelijk nogal een grote issue. En we willen geen file system of subversion beveiliging gebruiken, maar van onze eigen protocol. Daarom is het direct benaderen van subversion uit den boze.

Dan nog. Je zou HTTPS kunnen gebruiken, met Apache authenticatie middels een eigen Apache module die jullie protocol implementeert. Als het systeem zich automatisch vult moet het ook goed mogelijk zijn om de vul-algorithmen zo te structuren dat er een nette directory-structuur in komt.

[PhoneTech]

Manuzhai schreef op dinsdag 19 juli 2005 @ 14:26:
[...]
Dan nog. Je zou HTTPS kunnen gebruiken, met Apache authenticatie middels een eigen Apache module die jullie protocol implementeert. Als het systeem zich automatisch vult moet het ook goed mogelijk zijn om de vul-algorithmen zo te structuren dat er een nette directory-structuur in komt.

We zijn op geen enkele manier bezig met een web interface (gelukkig, html zuigt nogal hard). Misschien volgend jaar, maar eerst moeten we gewoon een simpel get, create en update DMS hebben voor de release in september.

Dan heb ik een paar maanden de tijd voor de webdav en swing repository browser