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.

• Um die Konzepte hinter der Ordnerstruktur zu verstehen blicke bitte in die Artikel Ordnerstruktur (allg.) und Ordnerstruktur „Mauerseglerei“.
• Eine gute ordnerstruktu ergibt sich nicht nur aus der Benennung der Objekte, sondern auch aus deren Anordnung in einem Baum. Siehe hierzu den Artikel Anordnung Regeln.

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?

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 YYYY–MM–DD, 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:

• Verhalten im gemeinsamen Datenspeicher

Automatisch generierte Liste aller Artikel zum Thema Datenspeicher:

Zuletzt bearbeitet am 5. Juli 2022 von Adrian Kowar