[Global Type] Abfrageschema

[Lars Kähler]

Moinsen!

Gern möchte ich Euch ein Diagramm zur Diskussion vorwerfen. Es dient dazu, den bestehenden Datenbestand zu erweitern und soll in HTML-Formularen umgesetzt werden. Die Einträge landen dann in einer temporären Tabelle, bis sie einer der Inspectors freischaltet und damit allgemein zugänglich macht.

Abfrage 20111001.pdf

[Sebastian Nagel]

Sieht für mich auf den ersten Blick schlüssig aus.

Was vielleicht etwas zu kurz kommt (was aber immer ein organisatorisches Problem darstellen kann) ist das Thema der Familie/Sippe und in Folge dann die Einordnung in DIN.

Beispiel Thesis: Slab, Mix, Sans und Antiqua ... das sind 4 Familien in einer Sippe. Diese Gruppierung sollte meiner Meinung nach irgendwo möglich und ersichtlich sein, da sie für den Anwender nützlich ist (sichere Bank beim Schrift-Mischen), und dem Entwurfsgedanken aller Sippen/Familienmitglieder zugrundeliegt.

Vielleicht lässt sich das über eine Funktion "Familie X ist originär mit ... verwandt" verknüpfen?

[Lars Kähler]

Meines Wissens die erste Schriftsippe mit Angehörigen aus unterschiedlichen Schriftgruppen war doch die Corporate A (Antiqua), E (Egyptienne) und S (Sans) von Kurt Weidemann, oder nicht? So etwas sprengt einfach die DIN. Oder es gibt eine Mehrfachzuordnung wie bei den Fontformaten jetzt schon. Bei der ATypI gibt es übrigens eine neue Special Interest Group zur Schriftklassifikation. Danach werde ich mich dann richten.

[Ralf Herrmann]

Am besten dazu mit Indra Kupferschmid beraten. Das ist ihr Spezialgebiet.

Ich stimme aber zu: Die Einordnungen in Sippen und Klassifikationen ist das eigentlich knifflige an jeglichen Schriftdatenbanken. Das Datenbank-Schema muss dies von Anfang an berücksichtigen – im laufenden Prozess ist es dann schwer dies noch umzusetzen.

[Sebastian Nagel]

... Corporate A (Antiqua), E (Egyptienne) und S (Sans) von Kurt Weidemann, oder nicht? So etwas sprengt einfach die DIN. Oder es gibt eine Mehrfachzuordnung wie bei den Fontformaten jetzt schon.

Meines Wissens nach war das die erste, bei der drei Schriftfamilien aufeinander abgestimmt waren und den selben Namen (+Zusatz) trugen.

Inzwischen gibt es das ja recht häufig – somit ist die Anforderung, das systematisch zu erfassen einfach gegegeben und die DIN wird der Realität nicht mehr gerecht.

Und auch davor waren schon einige Schriften auf gemeinsame Verwendung hin abgestimmt (z.B. bei Frutiger), wenn auch noch nicht mit vollem Konzeptgedanken und Benennung – ob man das aber berücksichtigen kann/soll, ist schon die nächste Frage.

Für die Datenbank hieße das grob umrissen: jeder Schrift(familie) können beliebig viele "konzeptionell verwandte" Schrift(famili)en zugeordnet werden. Es gäbe also nicht nur einen hierarchischen Baum mit Ästen, sondern auch Querverbindungen zwischen den Ästen – oder aber eine mehrdimensionale Matrix, in die jede Schrift einsortiert ist. Die Dimensionen könnten dann einerseits die DIN-Kritierien sein, aber eben um andere, vielleicht zeitgemäßere Perspektiven ergänzt sein (Matrix Willberg, ...).

Aber: Damit steigt auch der Aufwand beim Einstellen signifikant an!

[Lars Kähler]

Die Dimensionen könnten dann einerseits die DIN-Kritierien sein, aber eben um andere, vielleicht zeitgemäßere Perspektiven ergänzt sein (Matrix Willberg, ...).

Aber: Damit steigt auch der Aufwand beim Einstellen signifikant an!

Wir haben die Möglichkeit vorgesehen, alternativ zur DIN auch weitere Schriftenklassifikationen einzuführen. Insbesondere interessiert es mich, wie sich die Special Interest Group Type Classification der ATypI entwickeln wird. Danach werde ich mich auf jeden Fall richten. Wie Du im ERM an den drei Entitäten ganz links sehen kannst, ist die Option dann eingebaut.

[Lars Kähler]

Sorry, das ERM hier noch einmal:

http://i54.tinypic.com/mt9dtx.jpg[/img]"]

bearbeitet September 26, 2011 von Lars Kähler

[Lars Kähler]

Hm – das Bild war zu breit. Hier das ERM als PDF. Es geht um die drei Entitäten links außen – systems of classifications, groups of classifications, groups of classifications to typefeaces allocations.

110705_global-type.pdf

[Ralf Herrmann]

Das besagte Problem steckt da schon drin. Den Klassifikationsgruppen werden »Schriftfamilien« zugeordnet. Aber was ist nun, wenn die Familienmitglieder zu anderen Gruppen gehören?

In diesem System müsste zwanghaft jede Unterfamilie selbst zu Familie erklärt werden.

Was ich rein datenbanktechnisch auch nicht verstehe, sind die Zuordnungstabellen. Warum gibt es da mehr als 2 Einträge? Also weights_to_designers_and_foundies und typefaces_to_designers_and_foundries. Das provoziert auch Probleme, wenn einzelne Datensätze nicht in dieses Schema passen. Ganz zu schweigen von wiedersprüchligen Angaben, die in so einer Tabelle möglich wären.

[Lars Kähler]

Am besten dazu mit Indra Kupferschmid beraten. Das ist ihr Spezialgebiet.

Danke für den Tip. Ich habe ihr mal eine PM geschickt.

Ich stimme aber zu: Die Einordnungen in Sippen und Klassifikationen ist das eigentlich knifflige an jeglichen Schriftdatenbanken. Das Datenbank-Schema muss dies von Anfang an berücksichtigen – im laufenden Prozess ist es dann schwer dies noch umzusetzen.

Ich dachte mir, dass schlicht Verzweigungen möglich sind. Nach dem Prinzip: Schrift xy kommt in Klassifikation A in die Schublade m, bei Klassifikation B in die Schublade n.

Ralf: Vielen Dank, dass Du hier einmal auf das ERM eingegangen bist. Das war bisher das erste Feedback, das ich überhaupt erhalten habe.

Wie war es denn in Reykjavik? Wie ist der Vortrag gelaufen? Du bist noch dort oben?

[Ralf Herrmann]

Ich dachte mir, dass schlicht Verzweigungen möglich sind. Nach dem Prinzip: Schrift xy kommt in Klassifikation A in die Schublade m, bei Klassifikation B in die Schublade n.

Das schon. Von typeface gibt es eine 1:n-Verbindung zu groups_of_classification. Aber es gibt weder eine Möglichkeit Unterfamilien anzulegen, noch einzelne Schnitte einer Familie unterschiedlichen Gruppen zuzuordnen. Bei Superfamilien mit verschiedenen Stilen innerhalb einer Familie brauchst du das aber.

So ein Datenbank-Modell ist auch nicht einfach zu verstehen. Kein Wunder, dass du da kaum Feedback bekommst. Eigentlich musst du erst alle theoretischen Möglichkeiten mit Typo-Leuten durchsprechen und dann mit einen Datenbank-Experten diese Umsetzen. Die zwei Welten sind naturgemäß schwer zu vereinen.