Denne artikkelen er i sin helhet maskinoversatt.

Når du aktiverer en navnekonvensjon i en mappe, tilpasser prosjektteam ofte dynamiske blokker for å passe til spesifikke interne sporingsarbeidsflyten.

Nedenfor er praktiske eksempler på hvordan ulike team bruker egendefinerte felt og Dokumentidentifikator-bryteren for å opprettholde et organisert arbeidsområde.

Følgende saker beskrives i denne artikkelen:

Bruken av navnekonvensjoner drives vanligvis enten av et mandat fra prosjekteieren eller av et ønske blant prosjektmedlemmer om å få et klarere overblikk over filene sine.

En strukturert navnekonvensjon lar teammedlemmer søke etter spesifikke komponenter i dokumentnavn mer effektivt.

Uansett hvem som initierer arbeidsflyten, må prosjektmedlemmer kontakte en prosjektadministrator for å konfigurere og aktivere navnekonvensjonen, da administratortilgang kreves for å endre disse innstillingene.

Omfanget av implementeringen avhenger generelt av hvem som ber om det:

Når en konvensjon kreves av prosjekteieren, implementeres den ofte på hele prosjektet.

I disse scenariene opprettes ofte en separat, utpekt mappe for å romme dokumenter som ikke oppfyller de strenge konvenjonskravene.

Når en konvensjon bes om av en enkeltperson eller en bestemt undergruppe for å forbedre en lokalisert arbeidsflyt, aktiveres den vanligvis bare i deres spesifikke arbeidsmapper, mens resten av prosjektteamet fortsetter å fungere uten konvensjon.

Versjonsekvensering brukes til å spore påfølgende fileoppdateringer.

Avhengig av prosjektkrav velger team mellom utvidbare variable-lengde-spor, rigide bindestrek-polstrede plassholdere eller enkle numeriske indikatorer.

Følgende saker beskrives i denne delen:

2.1.1 Teamet

Liam (BIM-leder) og Sophia (Konstruktøringeniør).

2.1.2 Arbeidsflyten

Sophia laster jevnlig opp strukturelle modellfiler til plattformen.

Liam krever at alle innkommende modeller skal være eksplisitt merket med standard versjonsekvenser som v1, v2 eller v3.

2.1.3 Atferd og hensyn

Selv om dette oppsettet er enkelt i begynnelsen, kan versjonsspor utvides til doble eller trippeltall (f.eks. v10 eller v123) etter hvert som prosjektet fremskriter.

For å imøtekomme denne veksten etableres et tekstfelt med enten uendelig (variabel) lengde eller større fast lengde.

En viktig visuell vurdering med denne tilnærmingen er at hvis blokken befinner seg i midten av filnavnet, vil tillegg av et annet eller tredje tegn til sekvensen visuelt forskyve alle påfølgende navneblokker over tegn-plasser.

For å forhindre at disse skiftende versjonsetikett­ene oppretter helt separate dokumentbeholdere under hver opplasting, må dokumentidentifikatoren deaktiveres.

2.1.4 Konfigurasjonen

2.1.5 Resultatet

Når Sophia laster opp filer med navn som Structural_Model_v1.ifc og Structural_Model_v10.ifc, gjenkjenner plattformen de endrede versjonsstengene.

Filene stabiles pent som sekvensielle revisjoner under en enkelt, statisk dokumentbeholder med navn Structural_Model.

2.2.1 Teamet

Sarah (Lederarkitekt) og Tom (BIM-koordinator).

2.2.2 Arbeidsflyten

Sarah utsteder arkitektoniske tegninger som følger en progresjon der den første utgivelsen starter med et dobbelt bindestrek (--), fulgt av alfabetisk sporing (-a, -b) når endringer oppstår.

Hun samarbeider med Tom, som administrerer mappeoppsettet.

2.2.3 Atferd og hensyn

I motsetning til standard versjonsekvens holder dette bindestrek-polstrete oppsettet blokkens lengde nøyaktig den samme.

Når en ny versjonsbokstav introduseres, ofres en plassholder-bindestrek for å opprettholde jevn avstand.

En primær utfordring med denne strategien er at når alle plassholder-bindestrekene innenfor den forhåndsdefinerte lengden er oppbrukt, bryter konvensjonen.

Derfor anbefales denne tilnærmingen kun når det er en klar forståelse av grensen for maksimal revisjon for dokumentene.

2.2.4 Konfigurasjonen:

2.3.1 Teamet

David (Konstruksjonstegnmann) og Chloe (Leder konstruktøringeniør).

2.3.2 Arbeidsflyten

David oppdaterer tegninger med konstruksjonsdetaljer hyppig og merker dem numerisk på sin datamaskin ved hjelp av sekvensielle indikatorer som 01, 02 og 03.

Chloe gjennomgår disse detalj­ene og stoler på at plattformen sikrer at David legger inn tall i stedet for tilfeldige tekstbokstaver.

2.3.3 Atferd og hensyn

En heltall-fokusert regelblokk legges til mappestrukturen for å validere oppføringer.

Merk at selv om det sikrer at bare numeriske oppføringer brukes, godtar systemet ethvert gyldig heltall i stedet for å tvinge en streng, trinnvis sekvensiell telling.

2.3.4 Konfigurasjonen

2.3.5 Resultatet

Når David laster opp Steel_Detail_01.pdf, bekrefter heltallsfeltet at blokken inneholder numeriske data og tillater opplastingen.

Hvis David gjør en feil og prøver å laste opp en fil som inneholder bokstaver i denne blokken, avviser systemet filen.

Chloe kan overvåke filene vel vitende om at selv om plattformen godtar ethvert gyldig heltall og ikke tvinger David til å telle opp i en stiv kronologisk sekvens, garanterer den en ren numerisk tidslinje i filinformasjonsruten.

3.1 Teamet

Elena (HVAC-ingeniør) og Marcus (Prosjektleder).

3.2 Arbeidsflyten:

Elena bruker et lokalt navnesystem der hun legger til enkeltbokstav-forkortelseskoder for å indikere en tegnings livssyklustatus: W for Under utarbeidelse, D for Utkast og P for Publisert.

Marcus, prosjektlederen, må kjenne den nøyaktige statusen for ingeniørarkene hennes med et øyeblikk, men foretrekker fulle, beskrivende ord i stedet for forkortelser.

3.3 Atferd og hensyn

En rullegardinkonfigurasjon brukes på mappen for å bygge bro mellom lokale forkortelseskoder og plattformmetadata-visningstitler.

3.4 Konfigurasjonen:

3.5 Resultatet

Når Elena laster opp HVAC_Layout_W.pdf, samsvarer systemet koden W og fyller automatisk metadatavisningen som Under utarbeidelse.

Når Marcus utvider høyre informasjonsmeny for å gjennomgå filen, forblir dokumentnavnet et rent, statisk HVAC_Layout, mens delen Revisjonsopplysninger eksplisitt viser «Under utarbeidelse».

Følgende saker beskrives i denne delen:

Oliver (Dokumentkontroller) og Emma (Stedleder).

Oliver behandler daglige stedrapporter og må spore nøyaktig når hver rapport ble generert.

Emma, stedlederen, får hyppig tilgang til dokumenttabellen og krever at filene er svært organisert.

Fordi innebygde datoblokker ikke brukes innenfor navnekonvensjoner, bruker Oliver og Emma egendefinerte numeriske felt for å legge inn datostrenger.

De utforsker to distinkte konfigurasjonsvariasjoner avhengig av hvordan de vil at filene skal fungere.

I denne variasjonen endres datoen med hver ny filopplasting og representerer en ny revisjon av dagloggen.

Oliver bruker to siffer for dagen (01–31), to siffer for måneden (01–12) og enten et tosifret år (26, 27) eller et firesifret år (2026, 2027).

Fordi en navnekonvensjon bare tillater ett primært separatortegn på tvers av blokkene, krever håndtering av et isolert datoformat valg mellom to distinkte konfigurasjonsveier:

4.3.1 Tre separate heltallsblokker

4.3.2 Enkelt tekstblokk med interne separatorer

I denne variasjonen vil Emma at datoen skal være synlig i dokumentnavnet slik at separate filer finnes for hver dag.

Videre krever Emma at dokumenttabellen sorterer filene i perfekt kronologisk rekkefølge automatisk.

Lister innenfor plattformen sorteres alfanumerisk i henhold til Unicode-verdier.

Hvis en dato er skrevet som dag-måned-år, sorterer listen først etter dagsnummeret, og grupperer alle filer fra "01"-dagen fra ulike måneder sammen.

For å forhindre dette, plasserer Oliver året først, etterfulgt av måneden og deretter dagen.

Ved administrering av dette prefikset er det en balanse mellom å bevare tegenplass og sikre umiddelbar lesbarhet, noe som fører til to implementeringsalternativer:

4.4.1 To-sifret årprefikser (YYMMDD)

Dette alternativet forkorter sorteringsstrengen til en enkelt blokk for å eliminere ekstra separatortegn og reduserer året til to heltall (f.eks. 26, 27, 28).

Dette sparer tegenplass, noe som reduserer risikoen for at lange dokumentnavn blir avskåret eller trunkert på slutten av linjen i brukergrensesnittet.

Imidlertid oppgir dette alternativet umiddelbar lesbarhet.

En datostreng som 260126 kan lett bli misforstått, da det ikke er umiddelbar klart hvilke tall som representerer året og hvilke som representerer dagen.

Et mønster blir først gjenkjennbart etter visning av flere filer, og forskjellen blir bare tydelig når en dag eller årverdi overstiger 31.

4.4.2 Fire-sifret årprefikser (YYYYMMDD)

Dette alternativet bruker et fullstendig firesifret år (f.eks. 2026, 2027, 2028) på begynnelsen av navnet.

Denne konfigurasjonen forbedrer klarhet og umiddelbar lesbarhet betydelig, noe som gjør den kronologiske sekvensen åpenbar for alle teammedlemmer.

Imidlertid bruker det mer tegenplass på begynnelsen av filnavnet, noe som øker sannsynligheten for at informasjon på slutten av lange dokumentnavn blir trunkert eller skåret av i grensesnittet.

4.4.3 Konfigurasjon

4.4.4 Resultat

Når Oliver laster opp filer som 260115_Report.pdf og 260201_Report.pdf, opprettes separate dokumenter fordi dokumentidentifikatoren er aktiv.

Fordi året og måneden kommer først og bruker konsistent tosifret polstring, sorterer dokumenttabellen filene i upåklagelig kronologisk rekkefølge.