Namenskonvention für Dateien und Ordner

Namenskonventionen sind ein notwendiges Mittel zur Erhaltung unsere Ziele für eine gesunde Ordnerstruktur und ist vor allem für unsere gemeinschaftlich genutzten Datenspeicher (Netzwerkordner) relevant.

Kurzfassung

  • So kurz wie möglich, so lang wie nötig.
  • Dateien sollten anhand des Namens eindeutig identifizierbar sein.
  • Bestandteile (alle optional) eines Dateinamens und deren Reihung:
    • Typ (siehe Liste unten)
    • Datum (YYYY-MM-DD)
    • Subjekt (Thema, Kommunikaitonspatner,…)
    • Nummer (laufende Nummer, Version,…)
    • Freitext
  • Unterstriche nur einsetzen, wenn explizit nötig.
  • Punkt, Komma, Bindestich sind erlaubt (Details siehe unten).
  • Umlaute etc. nicht umschreiben (unnötig).
  • Kürzel vermeiden.
  • Keine floating Folders erstellen.

Weitere Informationen und Details zu den Regeln weiter unten.

Ziele

Die Ziele dieses Beschlusses sind ein Teilbereich jener Ziele, die im Artikel Ordnerstruktur beschieben sind.

In diesem Artikel definieren wir zudem folgende Ziele, bzw. machen explizit:

  • Aus dem Dateinamen lässt sich leicht auf den Inhalt schließen.
  • Die Suche führt mit hoher Wahrscheinlichkeit zu einem Erfolg.
  • Die Sortierbarkeit der Dateien wird gewährleistet.

Abgrenzung

Dieser Artikel befasst sich nur mit der Benennung einzelner Dateien und Ordner.

Allgemeine Regeln

  • Kurz halten
    Der Dateiname sollte so kurz wie möglich (und so lang wie nötig sein). Eine aktuelle Obergrenze, die auf manchen Systemen nicht überschritten werden darf, sind 255 Zeichen, wobei dies nicht nur für den Dateinamen gilt, sondern für den gesamten Pfad.
    • Redundanzen im Pfad maßvoll einsetzen, siehe unten Punkt „Eindeutigkeit“
    • Keine „und„-Ordner, wenn nicht unbedingt nötig. Statt „Hof und Garten“ mache besser zwei Ordner „Hof“ und „Garten“.
    • Angabe von Details in Ordnernamen nahe des Stamms des Dateibaums vermeiden. Je weiter man zu den Blattknoten (also untersten Unterordnern) kommt, desto ungefählicher werden pfadverlängernde Maßnahmen wie Detailangaben.
  • Eindeutigkeit
    Ein Dateiname sollte so lange sein, dass er genügend Informationen beinhaltet um eindeutig identifiziert zu werden – auch außerhalb der Ordnerstruktur, in der sich die Datei befindet.
    Ein Beispiel: Natürlich scheint es auf den ersten Blick widersinnig in einem Ordner „Rechnungen“ die Dateien mit „Rechnung YYYY-MM-DD Firmenname.pdf“ zu benennen, zumal Rechnungen ja bereits aus dem Ordnernamen hervorgeht und dennoch empfehlen wir dies. Gleichzeitig wird bei Ordnern darauf hingewiesen in einen Ordner „Rechnungen“ keinen Ordner „Rechnungen 2019“ hinein zu platzieren, sondern lediglich den Ordner „2019“. Bei Ordnern gilt: Möglichst nichts verdoppeln, da die Pfadlänge sowieso schnell sehr lange wird.
    Was ist also bei einer Datei anders? File-Sharing. Wenn ein User eine Datei schnell weiterleiten will und sie z.B. per Drag-and-Drop in das e-Mail Programm zieht, dann kann der User den Datei-Namen nicht mehr vorher bearbeiten. Die Umstände die Datei zwischendurch auf den Desktop zu kopieren und die Datei umzubenennen nehmen wenige in Kauf.
  • Erleichterung der Suche
    Es mag durchaus vorkommen, dass die Eindeutigkeit einer Datei bereits durch Dokumententyp und Datum erreicht wird. Aber wonach sucht ein User üblicherweise, wenn er_sie z.B. eine spezielle Rechnung finden möchte: Firma oder Rechnungsnummer. Es ist also durchaus sinnvoll diese Daten auch im Dateinamen bereitzustellen.
  • Kürzel
    Kryptische oder untypische Kürzel sollten vermieden werden, da sie in der Regel in Vergessenheit geraten.
  • Floating Folders
    Erstelle keine „Floating Folders“, also Ordner, die mit # oder _ oder ähnlichen Symbolen beginnen, um sie ganz oben in einer Liste zu halten. Ausnahmen gibt es. Details und Begründung dazu im Artikel „Ordnerstruktur„.

Erlaubte Zeichen

Erfreulicherweise leben wir im 21. Jahrhundert und damit sind viele der limitierenden Regeln aus dem 20. Jahrhundert Geschichte

  • Leerzeichen sind erlaubt. Sie erzeugen keine Probleme mehr. Der Unterstrich hat als Leerzeichen-Ersatz ausgedient. Die Bedeutung des Unterstrichs ist jene, dass ich damit zwei eigentlich unabhängige Worte zu einen Begriff verschmelzen kann, was eigentlich nur für Variablen und Bezeichner häufig verwendet wird.
  • Umlaute und ein scharfes S stellen auch keine Probleme mehr dar (alle verwendeten Dateisysteme – vFAT, NTFS, HFS, EXT4).
  • Übliche Sonderzeichen wie Punkt, Komma, Bindestrich, Unterstrich, runde Klammern sind auch unproblematisch.
  • Zeichen, die absolut nicht verwendet werden dürfen sind: \ / : * ? “ < > |

Typische Bestandteile

  • Typ des Dokuments: Beschluss, Protokoll, Vertrag, Rechnung, Notizen,…
    Einen Typen anzugeben ist dann sinnvoll, wenn er sich nicht selbstverständlich aus der Dateiendung ergibt. Eine Datei „blabla.jpg“ mit dem Wort „Foto“ anfangen zu lassen ist nicht sinnvoll.
  • Subjekt
    Wir verwenden den Begriff Subjekt im Sinne der aristotelischen Logik (kategorisches Urteil), also jene Enität, über die eine Aussage getroffen wird.
    • Thema
    • Zielgruppe, externer Empfänger oder Sender
  • Status: z.B. „(in Arbeit)“
  • ID: Manchmal ist es sehr nützlich eine Identifikationsnummer im Dateinamen zu belassen. Dies ist sehr oft bei Photos der Fall (DCIM-1234567) und unheimlich hilfreich, wenn man das Original sucht.
  • Reihung: Manchmal ist es sinnvoll Dateien bzw. Ordner nicht alphabetisch anzuordnen, sondern nach einer individuellen Abfolge. Dies ist z.B. der Fall, wenn die Abfolge in einem Prozess dringend eingehalten werden soll und sich eine solche nicht natürlich ergibt.
  • Datum: Es gibt eine Vielzahl potentiell relevanter Datumsangaben: Rechnungsdatum, Datum des Kreistreffens, das protokolliert wurde, Fertigstellungsdatum. Manchmal kann ein Änderungsdatum Sinn machen, doch findet sich dieses eigentlich in den Dateieigenschaften. Gelegentlich möchte man eine neue Version allerdings als eigene Datei abspeichern, braucht daher einen eigenen Dateinamen und da ist das Änderungsdatum nahe liegend – man könnte aber auch eine Versionsnummer vergeben. Ein Erstellungsdatum ist eigentlich immer unnötig, da es in den Dateiinformationen enthalten ist.
  • Versionsnummer: Hier empfiehlt es sich bereits bei der Erstellung auf führende Nullen zu achten (s.u.) und um deren Bedeutung klar zu machen hat sich ein kleines vorangestelltes „v“ etabliert. Wenn man eine hierarchische Unterteilungen der Versionsnummern braucht (z.B. Major Release, Minor Release, Patch), so hat sich der Punkt als Trennzeichen etabliert.
  • Username: siehe Artikel „Username (Active Directory)

Gestaltung der Standardtypen von Bestandteilen

Typenliste

Diese Liste soll den Nutzer_innen die Information geben, welche Typen bestehen bzw. wie sie geschrieben werden. Diese Liste kann, wenn benötigt, erweitert werden.

Die nachfolgende Liste sollte noch überarbeitet werden! Was brauchen wir wirklich? Was fehlt?

  • Agenda
  • Angebot
  • Aufgabenliste
  • Bedienungsanleitung
  • Begleitschreiben
  • Berechnung
  • Bericht (über z.B. Schadensfälle)
  • Beschluss
  • Beschlussvorschlag
  • Beschreibung (z.B. für Objekte)
  • Budget
  • Budgetplan
  • Grundriss
  • Hauspost
  • Konzept
  • Konzeptvorschlag
  • Lieferschein
  • Liste
  • Logbuch
  • Protokoll
  • Rechnung
  • Schreiben
  • Skizze
  • Vertrag

Datum

  • Format: YYYY-MM-DD
  • Beispiel 2019-02-18 für 18. Februar 2019
  • Begründung:
    • optimale Sortierbarkeit: Dateien mit ähnlichem Datum bleiben am nächsten bei einander
    • internationaler Standard
    • im Gegensatz zu YYYYMMDD gut lesbar. Die Zeiten, in denen man Zeichen sparen musste sind vorbei.

Usernames

  • Format: übernommen von den Active-Directory-Usernames
    • Vorname_Nachname
    • Bindestriche in Doppelnamen
    • Kürzung, wenn es über 20 Zeichen wären. Meist der Vorname auf einen Buchstaben oder der zweite Teil eines Doppelnamens.
  • Begründung: siehe Artikel „Username (Active Directory)

Nummerierung, Reihnung, Versionsnummern

  • Format: führende Nullen verwenden
    Zuerst muss man sich überlegen wie viele Elemente dieser Art zu erwaten sind. Unter 10 keine Nullen, unter 100 eine führende Null, unter 1000 zwei führende Nullen, usw. Im Zweifelsfall lieber mit zu vielen führenden Nullen anfangen.
  • Begründung: ohne führende Nullen wäre die Sortierung beispielsweise: 1, 10, 11, 12, 2, 20, 201, 21, 3,…

Anordnung der Bestandteile

Hierbei sind vor allem folgende Aspekte zu berücksichtigen:

  • Sortierung
    Nach welchen Kriterien würde ein User die Daten am ehesten sortieren wollen?
    Gibt es die Möglichkeit diese Sortierung auch auf andere Weise zu erreichen?
  • Wichtigkeit
    Das Wichtigste sollte eher nahe am Namensanfang stehen, da man eher danach sucht und daher nicht so weit in den Dateinamen hineinlesen muss.
  • Verfügbarkeit
    Informationen die häufig bekannt sind können gerne weiter vorne eingereiht werden. Solche, die oft fehlen sind an vorderer Stelle eher nicht zu empfehlen, weil dies das Muster stört.
  • Vorwissen
    Was weiß der User über die Datei bzw. den Ordner den er_sie sucht? Das, was der User eher suchen würde, sollte weiter vorne stehen.
  • Input-Device
    Was dem Touchscreen-User vielleicht nicht so bewusst ist: Viele geübte Büroarbeiter_innen verwenden für die Arbeit lieber die Tastatur als die Maus, zumal es einfach schneller ist.

Wann fange ich mit was an?

  • Typ, Thema
    Dies ist der Standard
  • Datum
    Datumsangaben an erster Stelle machen nur dann sinn, wenn sich in einem Ordner viele Projekte, Vorgänge, Dokumenttypen vom selben Typus befinden, deren augenscheinliche Eigenschaft es ist, dass sie immer und immer wiederkehren. Man sollte aber bedenken, dass man die Daten auch über deren Erstellungsdatum sortieren kann, was die Voranstellung des Datums zum Zwecke des Sortierens in vielen Fällen obsolet macht.
  • Nummerierung
    Eine Reihung der Objekte zu erzwingen ist z.B. dann sinnvoll, wenn die Abfolge in einem Prozess dringend eingehalten werden soll und sich eine solche nicht auf natürliche weise ergibt.

Vorschlagserarbeitung 2021-12-18

Wir fangen bei Rechnungen an ein Konzept zu erstellen und adaptieren es dann, sodass es mehrere (alle) Typen umfasst (wenn möglich).

Unser allgemeiner Vorschlag lautet:

  • Typ der Datei (nicht im Sinne fon Format wie pdf, sondern inhaltlicher Einordnung, z.B. Rechnung, Protokoll,…)
  • Datum (wenn irgendwie einbringlich, im Format YYYYMMDD, optional HHhmm oder HHhmmmss, z.B. 2021-12-24 18h15m45, Datum soll die Zeit der Aktion, des Termins etc. repräsentieren).
  • Subjekt (z.B. Rechnungssteller, Arbeitskreis, wenn kein Bearbeiter das Subjekt ist, dann der Gegenstand, z.B. Küche)
  • Laufende Nummer oder Identifikationsnummer (z.B. Rechnungsnummer), wenn vorhanden. Startkürzel (noch) nicht definiert
  • Versionsnummer (optional), beginnend mit v
  • Frei zu definierender Bereich (z.B. für den Gegenstand Objekt) in runden Klammern

Beispiel anhand einer Rechnung

  • Typ (z.B. Rechnung.)
  • Datum
  • Subjekt: Rechnungssteller/Empfänger, Kommunikationspartner (Wer? Wen?)
  • laufende Nummer (wenn verfügbar, z.B. Rechnungsnummer), Identifikation anderer Art
  • optional Versionsnummer
  • Frei zu definierender Bereich (z.B. für den Gegenstand Objekt) in runden Klammern

Beispiel: Rechnung 2020-12-24 12345 Weihnachtsmann (Geschenke).pdf

Protokolle

  • Typ: Protokoll
  • Datum
  • Arbeitskreis
  • lfd. Nummer existiert nicht, daher nichts an dieser Stelle
  • optional Verisionsnummer
  • Optional Thema in Klammern

Beispiel: Protokoll 2021-12-18 AK la Casa v1 (Weihnachtsdekoration).docx

PDF mit dem Vorschlag zum Grundriss einer Küche. Originalname „Grundriss Küche.pdf“

  • Typ: Grundriss
  • Datum: Gibts nicht
  • Was? Gemeinschaftsküche

Beispiel: Grundriss (Küche).pdf

  • Typ: Grundriss
  • Datum fehlt
  • Subjekt: Gemeinschaftsküche (Küche war zu allgemein)

Budgettabellen

  • Typ: Budget
  • Datum: Jahr (hier reicht YYYY)
  • Subjekt: Arbeitskreis oder „gesamt“ (für die gesamte Mauerseglerei)
  • Version: v1 (optional)

Konfigurationsdatei in der IT

  • Typ: Config
  • Datum: YYYY-MM-DD (Stunden und Minuten nur, wenn sich an einem Tag mehrere Änderungen ergeben)
  • Subjekt: Core-Router
  • freier Bereich: (die relevantesten Änderungen)

Bilder: Dokumentation Wasserschaden

  • Typ: Foto
  • Datum
  • Subjekt: Wasserschaden Denkküche
  • Identifikation: Originaldateiname
  • freier Bereich in Klammer Details zu dem Bild

Musik: z.B. für Fest

  • Typ: weglassen, da sinnbefreit (mp3)
  • Datum: sinnlos
  • Subjekt: eindeutige Beschreibung des Musikstücks -> eigene innere Sortierung: Künstler – Album Track-Nr – Titel
  • freier Bereich

Beschluss

Am 11. April 2022 wird dem Team Ordnerstruktur die Dateinamenskonention zum Beschluss vorgelegt (zulässig weil in Domain der IT und das Team ist von der IT zwecks Erhöhung der Diversität erstellt worden).

Vorgelegt wird der am 18.12.2021 erarbeitete Vorschlag mit den oben genannten Bedingungen, Optionen und Formatierungen der Blöcke. Kurz zur Einnerung:
Typ Datum Subjekt lfd.Num. Version Freitext.Dateiendung

Weiterführende Artikel

Zusätzlich zu oben verlinkten Artikeln sind folgende Ressourcen eventuell relevant:

Automatisch generierte Liste aller Artikel zum Thema Datenspeicher:

Verhalten im gemeinsamen Datenspeicher 20.6.2022 23:29 by Adrian_Kowar Posted in: File-Server In diesem Artikel beschreiben wir, wie sich Nutzer_innen beim Arbeiten mit unserem gemeinsamen Datenspeichers (i.e. Netzwerkordner) verhalten sollen. Kurzfassung Es handelt sich um einen gemeinsam genutzten… Weiterlesen
Ordner Anordnung Regeln 13.5.2022 04:23 by Adrian_Kowar-Adm Posted in: File-Server Wie erstellt man eine nachhaltig effizient nutzbare Ordnerstruktur? Weiterlesen
Ordnerstruktur Fileserver Basisverzeichnisse (IT) 12.5.2022 17:08 by Adrian_Kowar-Adm Posted in: File-Server Dieser Artikel soll die Ordnerstruktur aus unserem Fileserver zwischen dem Stammverzeichisses und der Shares dokumentieren. Anwender_innen aus der Mauerseglerei sichen vermutlich eher nach der Ordnerstruktur des… Weiterlesen
Team „Ordnerstruktur“ 12.5.2022 15:49 by Adrian_Kowar-Adm Posted in: File-Server Dieses Team wurde von der IT ins Leben gerufen um die Ordnerstruktur "Mauerseglerei" im Rahmen der Erneuerung unseres gemeinsamen Datenspeichers neu zu gestalten und die nötigen… Weiterlesen
Ordnerstruktur „Mauerseglerei“ 10.5.2022 14:07 by Adrian_Kowar-Adm Posted in: File-Server ARTIKEL IN ARBEIT Wir werden im Rahmen unseres gemeinsamen Datenspeichers, den wir 2022 auf einem neuen Fileserver aufziehen werden, eine neue Ordnerstruktur erarbeiten. Dieser Artikel befasst… Weiterlesen
Resilvering 23.1.2021 10:54 by Adrian_Kowar Posted in: File-Server Dieser Befgriff beschreibt die Wiederherstellung der Redundanz nach Ausfall eines Datenträgers. Namensherkunft Die einfachste Form der Redundanz ist die Spiegelung, d.h. dass man eine exakte Kopie… Weiterlesen
Volume Manager 19.1.2021 21:35 by Adrian_Kowar Posted in: System-Software Die Idee hinter einem (Logical) Volume Manager ist es eine Abstraktionsschicht zwischen Datenträgern bzw. physischen Partitionen (Teilen von Datenträgern) und Volumes (Virtuellen Datenträgern, Logischen Partitionen, unter… Weiterlesen
Datenträger 17.1.2021 04:24 by Adrian_Kowar Posted in: Begriff Als Datenträger wird ein Medium bezeichnet, das der Speicherung von Daten dient. Dieser Artikel soll eine Übersicht darüber geben, welche Datenträger in der Mauerseglerei-IT Verwendung finden… Weiterlesen
Self-hosted TrueNAS-Server 7.12.2020 17:21 by Adrian_Kowar Posted in: Konzept Dieser Artikel behandelt Features, Einsatzzweck, Vor-/Nachteile eines selbst gehosteten TrueNAS-Fileservers und Anforderungen an einen solchen. Die Mauerseglerei verfügt über einen solchen in Form des Servers Dioptas-NAS.… Weiterlesen
Dioptas (NAS) 3.12.2020 16:48 by Adrian_Kowar Posted in: Server Der Host Dioptas fungiert als dedizierter Fileserver auf der Basis von TrueNAS mit einer Nutzkapazität von ca. 14 Terabyte. Er vereint die Datensicherheit von ZFS, User… Weiterlesen

Zuletzt bearbeitet am 5. Juli 2022 von Adrian_Kowar

5 Responses

  1. find ich alles gut nachvollziehbar. Offen ist für mich die Frage, ob/wie bei Bedarf im Dateinamen vermerkt werden kann von WEM die Datei bearbeitet wurde, z.B wenn es mehrere Versionen gibt, die von verschiedenen mitgliedern ergänzt wurden. Den Hinweis auf die person würde ich – dem Vorschlag dieses Artikels folgend – zum Schluss in Klammer setzen. Die eigentliche Frage ist: verwenden wir Vereinsinterne Namenskürzel?
    Adrian schreibt oben zum Thema Name: Username wie in ActiveDirectory verwenden, also vorname_nachname. Wär das auch so gemeint, wenn ich den Hinweis auf eine Person in einen Dateinamen packen will?
    was für mich dagegen spricht ist einfach die Länge – ja, Zeichen sparen im Dateinamen selbst ist vorbei, aber meine Erfahrung ist, dass die 255 zeichen für die Pfadangabe häufig limitierend sind! und dass es deswegen eben schon Sinn macht Zeichen zu sparen.
    Auch sonst fände ich in der gemeinsamen Arbeit oft Namenskürzel hilfreich – aber da gibt es nichts verbindliches, d.h. jeder Kreis macht es anders, mal so mal so. Macht es Sinn uns auf Namenskürzel zu verständigen, wo wir schon am Thema Dateinamenskonvention dran sind?

    • Adrian_Kowar sagt:

      Gut dich mit an Board zu haben. Das haben wir tatsächlich übersehen.

      Wo: Die individuelle Bearbeitung einer Datei setzt oftmals auf einer Versionsnummer (oder einem Datum) auf, daher scheint mir hinter der Versionsnummer (und damit beim Freitext) ein sehr geeingeter Platz zu sein.

      Was die Frage nach Namenskürzeln anlangt, so lässt sich dies auf eine Frage zurückführen:
      Ist die Datei, die ich mit dem Namen versehen will eine, die ich langfristig anhand dieses Namens finden will?

      • Namenskürzel sind kein langfristig stabiles Idetifikationskonzept. Bereits jetzt haben wir Kollisionen. Wird nicht besser mit der Zeit.
      • Namenskürzel sind nicht Suchefunktion-freundlich. Abkürzungen mit 2 Buchstaben gibt es wie Sand am Meer.

      Aber gerade Bearbeiter* sind ein gutes Beispiel, wo die genannten Nachteile quasi verpuffen. Der Rettungsanker ist hier Kontext. Wie viele FR haben 2021 im Haustechnikteam gearbeitet? Und Suche ich langfristig nach dem Bearbeiter mit der Suchfunktion? Unwahrscheinlich. Und sollte das in irgendeinem Fall mal Zutreffen kann ich ja noch immer auf den vollen Namen umschwenken. Daher finde ich Namenskürzel für Bearbeiter* ein nützliches optionales Konzept.

      PS: Was die gesamtpfadlänge betrifft:
      Verschiedene Maßnahmen helfen die kurz zu halten:

      • AD-Namen sind auf 20 Zeichen begrenzt, d.h. wir reden von weniger als 8% von der Pfadlänge
      • Wir passen künftig auf unsere Pfade auf. Pfade wie Belege/2020/Belege 2020 neu/… wird es nie wieder geben
      • Im Gegensatz zu Pfaden die du auf deinem lokalen Computer mit z.B. C:\BenutzerMeinnameDokumenteMauerseglerei… beginnen lässt haben wir hier \files.mauerseglerei.atMauerseglerei… und damit wieder je nach Setting ein bisschen was gespart

      Alles in allem würde ich die technische Sorge hinter der Nutzendiskussion hintanstellen.

  2. Ansonsten würde ich auch das hier sofort beschließen und mit der Umsetzung beginnen!

  3. Ich lese hier, dass Leerzeichen keinerlei Probleme mehr verursachen.
    Aber ist das wirklich so? Auch in Excel-Formeln bzw. automatisierten Dateibenennungen und Dateiverknüpfungen?
    Also z.B. wenn ich in einer Tabelle auf eine Zahl in einer anderen Tabelle verweisen möchte, deren Name variabel sein soll?

    • Adrian_Kowar sagt:

      In allen modenen Programmen (und Excel macht das auch ganz brav) sollten Dateinamen immer als gekapselte Texte behandelt werden. Unter Windows bedeutet dies, dass alls Verarbeitungsroutinen, die Dateien anhand deren Dateinamen anfassen, der Dateinamen zwischen zwei doppelte Anführungszeichen (also „…“) gesetzt wird. Der einzige Ort, wo Leerzeichen heutzutage noch ein Problem darstellen ist das Web. Da eine URL leine Leerzeichen enthalten darf wird das Leerzeichen durch den Code %20 ersetzt. Dies sollte allerdings nicht wichtig sein, da wir unsere Excels nicht auf unserer Website posten.

      Ich habe leider kein MS Office um dies selbst zutesten. Ich habe gerade zwei Libre Office Dokumente verlinkt und hier schreibt mir Libre folgendes in die Zelle: ='file:///C:/Users/adrian/Desktop/Hallo Welt.ods'#$Tabelle1.A1

      Libre Office vermeidet Stress mit Leerzeichen hier mit einfachen Anführungszeichen um den Pfad

Schreibe einen Kommentar