Dit artikel is volledig automatisch vertaald.

Er zijn verschillende manieren om uw mappen en documenten te structureren en een naam te geven.

Afhankelijk van uw projecttype kunnen verschillende structuren en naamconventies beter voor u werken dan andere.

Dit artikel bevat enkele handige tips bij het bepalen van hoe u uw data-omgeving kunt instellen.

De volgende thema's worden in dit artikel beschreven:

Er zijn verschillende factoren die kunnen beïnvloeden welke items in een structuur worden benoemd.

Vindbaarheid en padlengte zijn vaak belangrijke factoren.

De volgende thema's worden in dit gedeelte beschreven:

De persoon die de naam instelt, is vaak vertrouwd met de inhoud van het item dat wordt benoemd.

Persoonlijke documenten

Bij het benoemen van items voor persoonlijk gebruik is een persoonlijke manier van benoemen vaak het beste, omdat de persoon die het document benoemt het item later gemakkelijk kan vinden door ernaar te zoeken.

Zelfs de persoon die het item benoemt, kan later moeite hebben met het opnieuw vinden van hun eigen informatie.

Samenwerkingsdocumenten

Bij het benoemen van items voor samenwerking zullen meerdere personen met de verschillende items werken.

Namen van mappen worden daarom vaak vooraf in projecten gedefinieerd, zodat ze gemakkelijk herkenbaar zijn in de verschillende projecten van een bepaald type die tot dezelfde organisatie behoren.

Minimumvereisten

Minimumvereisten voor documentnaamgeving worden vaak overeengekomen.

Aangezien verschillende woorden verschillende betekenissen kunnen hebben voor verschillende mensen, is het vaak belangrijk om met het team te bespreken welke naamgevingen aan items worden gegeven, zodat iedereen weet wat items moet benoemen en waarnaar moet zoeken.

Het volgen van goede praktijken voor het benoemen van documenten is altijd behulpzaam, maar iedereen heeft zijn eigen voorkeuren.

Een naamgevingsstrategie die voor u logisch is, is niet altijd logisch voor anderen.

Teamgemeenschappelijke naamgevingsschema's

Binnen een team komen medewerkers aan een bestandsstructuur vaak overeen op een naamgevingsschema.

Dit kan een mondeling voorstel zijn, zoals mensen vertellen dat ze de datum in de naam moeten zetten, of het kan worden afgedwongen door een naamconventie te creëren volgens welke mensen hun bestanden moeten benoemen om überhaupt te kunnen uploaden.

Projectgemeenschappelijke naamgevingsschema's

In een gemeenschappelijke data-omgeving komen vaak meerdere teams samen.

Teams hebben mogelijk nog geen naamregel op plaats of willen de hunne niet veranderen, maar als zij hun documenten al zeer lange tijd op één manier hebben benoemd, kan het moeilijk zijn hen te overtuigen het anders te doen.

In dit geval is een goede oplossing om mensen bestanden met hun voorkeursnaam te laten uploaden, zolang ze de naam van het document dat het bestand bevat, veranderen naar de conventie die door het project is overeengekomen.

Op deze manier kan het teamlid het document vinden via de oorspronkelijke naam van het bestand, terwijl een projectlid het kan vinden via de documentnaam.

Het beschrijvend zijn en het uitschrijven van volledige woorden kan hierbij helpen, omdat u het woord kunt lezen en in één oogopslag de inhoud van het document kunt begrijpen.

Dit betekent niet dat de documentnaam een hele zin moet zijn.

Documentnamen die te lang zijn om te lezen, kunnen eruit zien als een tekstmuur en worden snel genegeerd.

Het wordt daarom aanbevolen namen op 1 tot 5 woorden te houden.

Externe beperkingen

Binnen Catenda kunnen mapstructuren van elke padlengte worden geïmporteerd en geëxporteerd.

Andere software waarmee deze informatie wordt uitgewisseld, kan beperkingen hebben op het totale aantal tekens van de bovenliggende mappen en de documentnaam die het pad naar een document in de structuur vormen.

Zip-bestanden worden vaak gebruikt voor het uitwisselen van mapstructuren.

In Windows is de padlimiet voor zipbestanden bijvoorbeeld 260 tekens.

In OneDrive en SharePoint is deze limiet verhoogd, maar nog steeds beperkt tot 400 Unicode-eenheden.

Een typische situatie waarin mensen terechtkomen, is dat ze hun document iets als volgt noemen:

Presentation_Final

Als u vervolgens een wijziging moet aanbrengen, wordt het: Presentation_Final_Final, Final_Final_For real, Final_LastOneIPromise. Op dat moment geeft u het op en noemt u het volgende gewoon: Presentation_Submitted Deze situatie kan worden voorkomen door van het begin af aan een versieconventie vast te stellen.

U kunt uw bestand starten met Presentation_v1, Presentation_v2, enz...

Dit zorgt ervoor dat verschillende versies van hetzelfde bestand in een logische volgorde worden opgeslagen.

Hoewel er een goed revisiesysteem op Catenda is, kan het nog steeds zinvol zijn een versienummer toe te voegen.

Soms verschilt uw lokale revisietellingen van die welke u hebt geüpload.

Stel dat u v3 van de presentatie hebt geüpload, maar de volgende is v5.

De revisie op Catenda wordt met één verhoogd, terwijl uw lokale revisie met 2 is verhoogd.

Op deze manier kunt u bijhouden welke versie de juiste is.

Historisch gezien hebben systemen moeite gehad met spaties in documentnamen.

Hoewel veel systemen tegenwoordig spaties in documentnamen kunnen verwerken, kunnen er nog steeds redenen zijn om spaties uit documentnamen te verwijderen.

U wilt mogelijk twee woorden samen kunnen zoeken die geen twee afzonderlijke woorden zijn.

U kunt ook hopen het aantal tekens in een naam te verkleinen door de spaties te verwijderen.

Wanneer u een normale bestandsnaam gebruikt zoals:

this is a normal file name that is very long with many words.png

en u verwijdert de spaties, wordt het een onleesbare warwinkel, omdat u visuele aanwijzingen nodig hebt voor waar de woordgrenzen liggen:

thisisanormalfilenamethatisverylongwithmanywords.png

Als compressie uw doel is, wilt u niet elk woord met een ander teken scheiden, omdat u terug zou gaan naar dezelfde lengte als eerder.

In plaats daarvan kunt u elk woord met een hoofdletter schrijven.

ThisIsANormalFileNameThatIsVeryLongWithManyWords.png

Hoewel dit al iets beter is, is het bij langere namen nog steeds behoorlijk moeilijk om te lezen.

Als het doel is de ruimte te minimaliseren, kunt u proberen woorden die bij elkaar horen, te groeperen:

ThisIs_ANormalFileName_ThatIs_VeryLong_WithManyWords.png

Nu treden we het territorium in van een goedenaam, korte bestandsnaam die leesbaar is.

Zelfs wanneer bestandslengte niet logisch is, is het zinvol om na te denken over het comprimeren van woorden op deze manier, omdat het gemakkelijker is om gegroepeerde woorden in één oogopslag te begrijpen.

Als u niet geeft hoeveel uw bestandsnaam wordt, kunt u wat u nog beter kunt doen, is het introduceren van een secundaire scheidingsteken.

Zie hier hoe gegroepeerde woorden op één manier worden gescheiden, terwijl de woorden in elke groep op een ander manier worden gescheiden.

This-is_A-normal-File-name_That-is_Very-long_With-many-words.png

Merk op dat door elk woord te scheiden, het mogelijk was elk eerste woord met een hoofdletter te schrijven en vervolgens kleine letters voor de volgende.

In gevallen waar er veel verschillende documenten zijn die allemaal iets anders zijn, heeft het geen zin om dezelfde 4 woorden steeds opnieuw te herhalen om slechts een variatie op het 5e woord toe te voegen.

In dit geval kunt u een afkorting voor elk woord gebruiken.

Voorbeeld: Architecture kan ARC worden, Eerste verdieping kan 1e worden.

Het feit dat u meer informatie in minder ruimte kunt hebben, is zowel een sterkte als een zwakte.

Hoewel het gemakkelijk is om 100% correct te zijn met de bestandsnaamgegevens op deze manier, is dit niet altijd de beste manier om uw bestanden te benoemen.

Wanneer u afkortingen toevoegt, merkt u al snel dat uw bestandsnamen in een warwinkel van onleesbare bende veranderen.

Neem bijvoorbeeld: 20110101_ARC_BLDG1_BLCK2_FLR4_Q4_Wa3_Win4_S_C_v4 Hoewel het voor de bestandsauteur logisch kan zijn dat dit een bestand was van: 1 januari 2011 over de vierde versie van een betonnen dorpel in raam 4 op muur 3 op verdieping 4 op blok 2 in gebouw 1 door de architect.

Ik ben er vrij zeker van dat niemand anders in het project de tijd zal nemen om het te lezen.

Zeker niet wanneer wat de zoekopdracht echt zocht:

20110101_ARC_BLDG1_BLCK1_FLR4_Q4_Wa2_Win3_S_C_V4

Dit is een helemaal ander raamwerk!

Als het tot dit niveau komt, is het beter om uw bestanden in mappen op te splitsen.

De documentsectie wordt automatisch op naam gesorteerd.

Het kan daarom een goed idee zijn om enkele tekens aan het begin van het document toe te voegen, zodat het meest relevante document eerst verschijnt.

Chronologische volgorde

Om een historisch overzicht op Catenda Hub te krijgen, kunt u altijd sorteren op gepubliceerd of gemaakt.

Standaard worden de Documenten op naam gesorteerd.

Wanneer een Lid een map voor het eerst opent, staat het meest recente document mogelijk niet bovenaan.

Om dit tegen te gaan, kunt u de datum van het document aan het begin van het document toevoegen: 20110101 zou de eerste januari 2011 zijn.

Dit kan ook handig zijn als u Documenten hebt die lang geleden zijn gemaakt en vervolgens naar Catenda Hub zijn geïmporteerd.

Hoewel deze naam kan worden gewijzigd, kan het nuttige informatie zijn wanneer u naar een document zoekt.

Op deze manier kunt u ook de naamkolom op datum sorteren.

Alfanumerieke volgorde

Raadpleeg de sorteerorde van lijsten op Catenda om erachter te komen welke tekens voor andere tekens worden geplaatst.

Om uw documenten in volgorde van belang te krijgen, kunt u altijd sorteren op labels of aantal revisies.

Standaard worden de documenten op naam gesorteerd.

Wanneer een lid een map voor het eerst opent, staat het belangrijkste document mogelijk niet bovenaan.

Om dit tegen te gaan, kunt u een teken aan het begin van de naam toevoegen dat ervoor zorgt dat deze het eerste verschijnt.

U kunt uw bestanden bijvoorbeeld noemen: 1.0 Most important. 1.1 Less important, 1.2 enz... Vervolgens merkt u misschien op dat iemand uw regel doorbreekt door per ongeluk een document met een 0 aan de voorkant te uploaden, wat als eerste verschijnt.

Wat u vervolgens kunt doen, is een _ aan het begin van de naam toevoegen om ervoor te zorgen dat deze voor elk item verschijnt.

Deze strijd om wie het eerste is, kan eindeloos lijken.

Het kan daarom helpen om naar de sorteerorde van lijsten te kijken om te zien welke tekens voor anderen worden geplaatst om te zien wat voor uw geval logisch is.

Het kan moeilijk zijn informatie te vinden als er veel informatie in een lijst staat en u ver naar beneden moet scrollen om de gewenste informatie te vinden.

De volgende thema's worden in dit gedeelte beschreven:

Als er te veel documenten of mappen in een map staan, kunnen ze moeilijk te vinden zijn, omdat u ver naar beneden in de lijst moet scrollen om het document te vinden dat u zoekt.

Op dit moment heeft het vaak zin om een submap aan deze lijst toe te voegen en de documenten naar hun belangrijkste eigenschap te verdelen.

Dit kan een reeks eigenschappen zijn, zoals:

Type document (Tekening, afbeelding, spreadsheet)

Gerelateerd onderwerp (Muren en ramen)

Studiegebied (ARC, MEP, STR)

Partij die het heeft geüpload (Groep 1, Groep 2, Groep 3)

Uploaddatum (20110101, 20231225)

Volwassenheid (Concept, Ingediend, Goedgekeurd, Geweigerd)

Redenen die de beslissing kunnen beïnvloeden over hoe u uw documenten verdeelt, kunnen zijn:

Vindbaarheid

Toegangscontrole

Na een tijdje met een documentstructuur te hebben gewerkt, zult u merken dat u veel submappen begint te maken.

Als het veel klikken kost om naar de submap te gaan, hebt u het probleem dat u probeerde op te lossen door submappen in de eerste plaats niet opgelost, omdat de informatie nog steeds moeilijk te vinden is.

Het wordt aanbevolen niet verder dan 3 lagen te gaan bij het maken van submappen.

Dit is omdat de meeste mensen de laatste twee mappen waaruit ze waren, kunnen onthouden, maar hoe dieper u gaat, hoe meer u begint te vergeten waar u vandaan komt.

Om dit te voorkomen, kunt u uw submappen naar een niveau omhoog verplaatsen.

Dit is een voorbeeld van een map die 4 niveaus diep is:

01_Models-and-drawings 0101_Models 010101_ARC 01010101_Window 01010102_Wall 010102_MEP 01010201_Ducts 01010202_Vents 010103_STR 0102_Drawings

Deze map kan als volgt worden vereenvoudigd:

0101_Models_ARC 010101_Window 010102_Wall 0102_Models_MEP 010201_Ducts 010202_Vents 0103_Models__STR 0201_Drawings

Of misschien nog eenvoudiger:

010101_Models_ARC_Window 010102_Models_ARC_Wall 010201_Models_MEP_Ducts 010202_Models_MEP_Vents 010301_Models__STR 020101_Drawings

Zoals u kunt zien, kan het toevoegen van meerdere soortgelijke mappen op hetzelfde niveau helpen het aantal klikken te verminderen dat nodig is om naar de map met de documenten die u zoekt te gaan.

Nog iets wat u misschien opmerkt, is dat hoe meer u de mapstructuur vereenvoudigt, hoe langer de bestandsnamen worden.

Als bestandsnamen te lang worden, worden ze moeilijk leesbaar.

Het is daarom belangrijk om een evenwicht te bewaren tussen bestandsnaamlengte en mapdiepte.

In deze documentstructuur structureert u uw bestanden volgens het type document.

Alle plattegronden gaan in de plattegrondmap, alle vergaderverslagen gaan in de samenvattingenmap, enz. Deze bestandsstructuur is voor de client gemakkelijker te gebruiken, omdat bestanden die door consultants worden bezorgd, allemaal op één plaats zijn verzameld.

Deze bestandsstructuur is voor de consultants moeilijker te gebruiken, omdat zij veel verschillende plaatsen hebben waar zij hun bestanden bezorgen.

Voorbeeld van bestandsstructuur

Een voorbeeld van dit type documentstructuur kan zijn:

0101_Informatie 010101_Beheer 010102_Contracten 0201_Afbeeldingen_Presentaties YYMMDD_Presentatietitel.ppt 0202_Afbeeldingen_Sitebezoeken YYMMDD_Sitebezoektitel.jpg 0301_2D 03010101_Plan_Vloer 030101010101_DWG_ARC YYMMDD_Tekeningstitel.dwg 030101010102_DWG_STR 030101010103_DWG_MEP 030101010103_DWG_LAN 030101010201_PDF_ARK YYMMDD_Tekeningstitel.pdf 030101010202_PDF_STR 030101010203_PDF_MEP 030101010203_PDF_LAN 03010102_Plan_Plafond 03010103_Plan_Nooduitgang 03010201_Dwarsdoorsnede 03010301_Aanzicht 0302_3D 03020101_Modellen_Archicad 030201010101_PLN_ARC 030201010102_PLN_STR YYMMDD_Tekeningstitel.ifc 030201010103_PLN_MEP 030201010104_PLN_LAN 030201010201_IFC_ARC 030201010202_IFC_STR 030201010203_IFC_MEP 030201010204_IFC_LAN 03020102_Modellen_Navisworks 03020103_Modellen_Revit 030201030101_RVT_ARC 030201030201_IFC_ARC 03020104_Modellen_Rhinoceros 03020105_Modellen_Solibri 03020106_Modellen_Puntenwolken 03020201_Visualisatie_Renderings 03020202_Visualisatie_Afbeeldingen-hoge-resolutie

In deze documentstructuur scheidt u eerst de verschillende studiegebieden die aan uw project deelnemen.

Dit type mapstructuur kan goed zijn als u uw gebruikers volledige toegang tot hun eigen gebied wilt geven, waar zij vrij bestanden kunnen verplaatsen als zij wensen.

Deze bestandsstructuur is voor de consultants gemakkelijker te gebruiken, omdat zij hun eigen gebied hebben waar zij controle hebben over alle bestanden die zij uploaden.

Deze bestandsstructuur is voor de client moeilijker te gebruiken, omdat bestanden van de verschillende consultants in elkaar hun eigen map zijn verspreid.

Voorbeeld van bestandsstructuur

0101_Informatie 010101_Beheer 010102_Contracten 0201_ARC 02010101_2D 02010201_3D_Archicad 0201020101_PLN 0201020102_IFC YYMMDD_Tekeningstitel.ifc 02010202_3D_Navisworks 02010203_3D_Revit 0201020301_RVT 0201020301_IFC 02010204_3D_Rhinoceros 02010205_3D_Solibri 02010206_3D_Puntenwolken 02010307_Contracten 0202_MEP 020201_2D 020202_3D 020203_Contracten 0203_STR 0204_LAN

Met modellen als documenten ingeschakeld, is het mogelijk modellen uit de modelensectie te verbinden met documenten in de documentsensectie.

Als nieuwe modellen in de modelensectie worden gemaakt, verschijnen zij in een map die de modellenmap wordt genoemd.

Modellen kunnen uit de modellenmap worden verplaatst en worden verplaatst naar waar u ze in de documentstructuur wilt hebben.

Vergelijkbaar met de bovenstaande voorbeelden kunt u uw modellen structureren op type: 01_Models -> 0101_ARC -> YYMMDD_Model-title.ifc

Of u kunt uw modellen per studiegebied structureren: 01_ARC -> 0101_Models -> YYMMDD_Model-title.ifc

De beste optie die u hier kunt kiezen, hangt af van of u denkt dat uw gebruikers het modellenfilter zullen gebruiken.

Als u modellen per studiegebied scheidt, kan het moeilijk zijn voor gebruikers om de 3D-modellen te vinden die vermengd zijn met de andere documenten van elk studiegebied.

Als u er zeker van bent dat uw gebruikers het modellenfilter zullen vinden, kunt u deze optie gebruiken.

Als u niet gelooft dat uw gebruikers dit filter zullen gebruiken, is het beter om alle uw modellen in hun eigen modellenmap te hebben, zodat de gebruiker zich ervan bewust is dat deze map modellen bevat die in 3D kunnen worden geopend.