Wie scanne ich das wohl am effektivsten?

[Ralf Herrmann]

Ich sehe allerdings das Problem, dass bei manuellem Einpflegen in die Bilder – erstrecht von verschiedenen Leuten – schnell inkonsistente Daten entstehen. Mal wird etwas groß, mal klein geschrieben, mal heißt es Schriftgiesserei, Schriftgießerei etc.

Da böte sich eine relationale Datenbank doch schon sehr an, wo die Informationen nur verknüpft sind und nicht fest in den Bildern verdrahtet. Und für die Freunde von XML braucht es ja dann am Ende nur eine Exportfunktion.

[[Mitglied Blei…]]

Ja, das ist ein Problem, das ich gut kenne.

Zwar wird das Problem kleiner, weil ja die jeweils korrekte Bezeichnung in den Abbildungen selbst stehen, aber durch die manuelle Eingabe wird es wohl zu Fehlern kommen.

Ich bin von morgen an bis einschließlich Samstag nicht da.

Und schlage vor, daß Ihr Euch hier bis dahin einig werdet, was Eure endgültige Empfehlung ist, auf die Ihr Euch einigen könnt. Sollte das nicht möglich sein, ist es nicht zu ändern und ich muß dann nach bestem Wissen allein entscheiden.

Ich möchte eine evtl. notwendige Programmierung dann nächsten Montag in Auftrag geben und das Projekt dann innerhalb der nächsten 14 Tage realisieren.

Gruß

Georg

[[Mitglied Þors…]]

Ich habe bei allen meinen Aktivitäten auch immer meine Reputation im Kopf, mache also (fast) nie etwas uneigennützig.

Oder positiver formuliert: Selbstständige und Freiberufler (sollten!) wissen, dass ihr guter Ruf ihr wichtigstes Verkaufswerkzeug ist und potentiell alles, was sie tun, ihren Ruf beeinflusst. D.h., dass selbst, wenn man etwas nettes für die Allgemeinheit tut, sich das durchaus positiv auf das eigene Geschäft auswirken kann.

Dabei ist weniger aber oft mehr. Schwingt man zu sehr den Holzhammer (Copyright-Markierungen allerorten, [wenig subtiles] Wasserzeichen auf jedem Bild) entsteht eben schnell der Eindruck, dass ein Projekt weniger ein Dienst an der Allgemeinheit ist als ein schnöder Werbegimmick. Und dann kann der gute Wille, den man eigentlich schaffen wollte, schnell ins Gegenteil umschlagen.

Konkret: ist der Umgang mit der Typokartei wenig restriktiv und nervend, besteht kaum ein Anlass, das ganze zu klauen und als Eigenbau neu zu »vermarkten«. Wird es von den Nutzern eher als Dienst an der Allgemeinheit aufgefasst denn als Eigenwerbung, werden mehr Nutzer auf die Projektseite verweisen, sie ihren Kollegen gegenüber positiv erwähnen etc. pp.

Ich würde z.B. erwägen, das ganze unter eine Creative-Commons-»by«-Lizenz zu stellen, die praktisch jede Weiterverwendung erlaubt, solange der ursprüngliche Autor entsprechend erwähnt wird.

Ursprünglich war geplant, einen jeden Scan mit einer Signatur, um 90° gekippt, links außen mit ins Bild zu nehmen: http://www.Bleisetzer.de

Wenn das so aussähe wie hier, erschiene mir das schon etwas zu holzhammermethodig.

Wenn ein entsprechender Hinweis mit auf das Bild soll, würde mir eher was vorschweben, was mehr wie ein Quellenhinweis aussieht als eine Website-Wortmarke. Also z.B. sowas wie »Schriftmusterkarte der Beisetzer.de-Typokartei«, ganz klein gesetzt am unteren Rand (nicht gedreht). Noch weniger werblich (und also mehr informativ) sähe es wohl aus, wenn du ein paar € in einen eigenen Domainnamen investieren könntest (typokartei.de?). Von dieser Website könntest du dann natürlich nach Herzenslust auf bleisetzer.de verlinken. (Ralf zeigt hier ja sehr gut, wie so etwas funktionieren kann. )

Wenn man diese Information mit in die Bilddaten hineinpacken könnte, empfände ich das als optimaler.

Das geht auf jeden Fall. Wahrscheinlich sollte man, wenn die Verschlagwortung abgeschlossen ist, einfach eine auf einer Untermenge der Schlagworte basierende Infozeile automatisiert in das Kommentarfeld des Bildes einfügen, z.B. »Typokartei.de-Schriftmusterkarte der Schrift Dominante kursiv, 1959«. (Das Kommentarfeld deshalb, weil das in den meisten Bildbetrachtungsprogrammen angezeigt wird.)

, Thorsten

[[Mitglied Diet…]]

Wenn man diese Information mit in die Bilddaten hineinpacken könnte, empfände ich das als optimaler.

Das geht auf jeden Fall.

Wenn es optimaler ginge, dann wäre das natürlich die maximalste, vielleicht sogar die einzigste Lösung.

[[Mitglied Pach…]]

Wenn es optimaler ginge, dann wäre das natürlich die maximalste, vielleicht sogar die einzigste Lösung.

Das wäre sicher am idealsten.

[[Mitglied Þors…]]

Wie schon geschrieben: wie die Verschlagwortung organisiert wird, ist weniger wichtig als das Format, das am Ende — hoffentlich viele Jahrzehnte lang — bequem benutzt und gepflegt werden kann.

Man kann JPEGs mittels XMP Metadaten mit auf den Weg geben.

Genau. Das ist ein Weg. Am Ende sollten die Metadaten auf alle Fälle in XMP in den Bildern stehen. Dazu wurde XMP entwickelt und wir sollten nicht versuchen, das Rad neu zu erfinden.

Ob man die Verschlagwortung direkt so machen sollte, hängt wohl davon ab, wie man das macht und ob es für den richtigen Weg ausreichende Softwareunterstützung gibt. So sollte man z.B. auf keinen Fall Standard-XMP-Felder zweckentfremdet nutzen oder gar Keywords wie »Schriftguss:1959« erstellen. Das wäre in der Tat fehleranfällig. Der richtige Weg wäre es, per XML-Schema vor dem Beginn der Verschlagwortung einen Satz von erweiterten Datenfeldern zu definieren und die dann zu befüllen. Aber wie geschrieben: wie das von den gängigen Bildverwaltungsprogrammen softwaremäßig unterstützt wird, weiß ich nicht. (Exiftools kann’s, damit sollte sich also z.B. ein simples Web-Perl-Script erstellen lassen.)

Ich sehe allerdings das Problem, dass bei manuellem Einpflegen in die Bilder – erstrecht von verschiedenen Leuten – schnell inkonsistente Daten entstehen. Mal wird etwas groß, mal klein geschrieben, mal heißt es Schriftgiesserei, Schriftgießerei etc.

Richtig. Die Verschlagworter dürfen die Feldnamen nie tippen müssen.

Da böte sich eine relationale Datenbank doch schon sehr an, wo die Informationen nur verknüpft sind und nicht fest in den Bildern verdrahtet.

Sicher. Oder auch ein validierender XML-Editor. Da bräuchte man statt einer kompletten Webapp+DB nur ein Tyopkartei-Schema, das die korrekten Felder vorgibt.

Sogar die Spreadsheet-Methode (Excel oder was auch immer) wäre nicht so schlecht. (Immerhin stünden da die Feldnamen nur in der Kopfzeile und müssten also nicht manuell eingetippt werden. Ein entsprechendes Template kann man ja bereit stellen.)

, Thorsten

[[Mitglied Josh…]]

Ich bin da Ralfs Meinung: Eine relationale Datenbank bietet sich an.

Folgendes schwebt mir ungefähr als optimale Lösung vor:

Für verschiedene Angaben wie Hersteller, Entwerfer usw. gibt’s eine eigene Tabelle in der Datenbank. Zu diesen Angaben gibt es also nur je einen Eintrag.

In der Haupttabelle werden die Schriften selbst gespeichert: Einige Angaben direkt (z. B. Name, Jahr), andere Angaben werden bloß verknüpft mit den anderen Tabellen.

Praktisch könnte das Erfassen der Daten so aussehen: Ein PHP-Skript zeigt eine Liste der Bilder. Klickt man auf eines der Bilder, öffnet sich eine Eingabemaske. Dort kann man dann gewisse Daten direkt eingeben, andere wählt man aus einer Liste aus. Fehlt in der Liste der gewünschte Eintrag (z. B. ein Hersteller), kann man selbst einen neuen Eintrag anlegen (der neue Hersteller wird dann in die Hersteller-Tabelle eingetragen).

So bleibt alles konsistent, es wird nichts redundant gespeichert, und es kann alles flexibel geändert werden. Die besonderen Angaben können zentral geändert werden, da sie ja nur verknüpft sind.

Ist alles erfaßt, kann man ja aus einer Datenbankabfrage ein Skript erstellen, das die Daten dann in die Bilder einträgt (mit ImageMagick oä. müßte das doch gehen).

Dann braucht man auch keine XML-Dateien mehr, um die Daten für die Nachwelt zu erhalten, denn sie stehen ja dann in den Bilddateien selbst.

MySQL ist quelloffen (und zwar die meistgenutzte quelloffene Datenbank), und die Datenbank-Schnittstelle SQL ist von der ISO normiert. Als MySQL-Datenbank wären die Daten damit meiner Meinung nach durchaus „nachhaltig“ gespeichert.

(Übrigens gibt es kostenlose Programme, die aus dBase-Datenbanken einen SQL-Befehl erzeugen, womit dBase-Datenbanken in jedes SQL-unterstützende Datenbankformat umgewandelt werden können.)

[[Mitglied Þors…]]

Ich bin da Ralfs Meinung:

Argumentum ad verecundiam!

Dann braucht man auch keine XML-Dateien mehr, um die Daten für die Nachwelt zu erhalten, denn sie stehen ja dann in den Bilddateien selbst.

Die Daten an sich sind sowieso für die Nachwelt erhalten; schließlich stammen sie aus dem Bild selbst. (Ich bin mir sicher, dass in 50 Jahren OCR so gut ist, dann man nur mit einem beliebigen Telefon an den Karten vorbei wedeln muss, um 1a-Text zu erhalten.)

Es geht gar nicht so sehr um die Erhaltung der einzelnen Datensätze, sondern um die noch im Aufbau befindliche Kartei. Dieses Dokument wäre in einem XML-Dokument explizit enthalten, in einer SQL-Datenbank aber nicht. Dort hättest du dann auch wieder nur eine Reihe von Datensätzen, die erst programmatisch wieder miteinander verknüpft werden müssten, um die Kartei »on the fly« zu erstellen.

MySQL ist quelloffen (und zwar die meistgenutzte quelloffene Datenbank), und die Datenbank-Schnittstelle SQL ist von der ISO normiert. Als MySQL-Datenbank wären die Daten damit meiner Meinung nach durchaus „nachhaltig“ gespeichert.

Wir treffen uns in 50 Jahren. Du bringst ein XML-Dokument für mich mit und ich einen Binärblob mit einer MySQL-Datenbank sowie die MySQL-Quellen für dich. Dann werden wir ja sehen, wer von uns schneller das jeweilige Dokument auf zeitgemäßer Computertechnik präsentieren kann.

[[Mitglied Mini…]]

Wir treffen uns in 50 Jahren. Du bringst ein XML-Dokument für mich mit und ich einen Binärblob mit einer MySQL-Datenbank sowie die MySQL-Quellen für dich. Dann werden wir ja sehen, wer von uns schneller das jeweilige Dokument auf zeitgemäßer Computertechnik präsentieren kann.

Aaaalso... Um das mal für einen EDV-Normalbegabten zusammenzufassen, also jemanden der als kleiner Junge bereits zum Vergnügen BASIC am C64 programmiert hat und trotzdem heutzutage nicht mal in der Lage ist, einen HTML-Footer so zusammen zu zimmern, dass er in Outlook nicht aussieht als wär er mit Blücher zusammengestoßen (wenn jemand ne helfende Hand reichen möchte... Ich beiß gleich n Stück aus meiner Tastatur...):

Sowohl XML als auch SQL sind ja nach einem bestimmten Schema in Klartext umzuwandeln: Jemand der nicht weiß welche 001100er-Kombination für ein A steht, der kann mit den Daten auch erstmal nichts anfangen. Wenn aber diese Stufe erstmal überwunden ist, dann sind XML-Dateien eindeutiger aufgebaut als SQL-Dateien? Also so in etwa nach dem Motto:

XML:

Datensatz1

Datum1

Datum2

Datum3

Datensatz2

Datum1

Datum2

Datum3...

SQL: Datensatz1, Datensatz2,... Datum1, Datum1, Datum1,... Datum3, Datum3...

Also quasi so, dass man eine XML-Datei mehr oder weniger auch ohne irgendeine Software auslesen könnte, oder ausdrucken und vom Blatt verstehen? Versteh ich das richtig? 8) Wenn ja, worin besteht dann der Vorteil einer Datenbank wie z.B. SQL?

[[Mitglied Cajo…]]

Also quasi so, dass man eine XML-Datei mehr oder weniger auch ohne irgendeine Software auslesen könnte, oder ausdrucken und vom Blatt verstehen? Versteh ich das richtig? 8) Wenn ja, worin besteht dann der Vorteil einer Datenbank wie z.B. SQL?

Die SQL-DB hat u.a. den Vorteil, dass mehrfach vorkommende Daten nur einmal gespeichert werden müssen. Es gäbe also wie schon erwähnt eine Tabelle mit mehreren Datenfeldern für die Schriften selbst, und dazu eine für die Entwerfer und eine für die Gießereien. Im Datensatz der Schrift wird dann nur noch auf den Datensatz der Gießerei verwiesen, diese aber nicht nochmal ausgeschrieben.

Der XML-Ansatz (also mit XMP) hat den Vorteil, dass die Daten direkt im Bild selbst gespeichert werden, also problemlos einzeln und offline weitergeben können.

Bleisetzer will seine Bilder auch auf CD etc. weitergeben, also wäre dafür die XMP-Lösung die sinnvollere. Dafür gibt’s vermutlich genug Programme, die das anzeigen und/oder bearbeiten können. Für die zentralisierte Eingabe wäre allerdings eventuell eine Datenbanklösung sinnvoll, aus der nach Abschluss der Eingabe die Daten automatisch nach XMP exportiert und in die Dateien geschrieben werden.

[Ralf Herrmann]

Wir treffen uns in 50 Jahren. Du bringst ein XML-Dokument für mich mit und ich einen Binärblob mit einer MySQL-Datenbank sowie die MySQL-Quellen für dich. Dann werden wir ja sehen, wer von uns schneller das jeweilige Dokument auf zeitgemäßer Computertechnik präsentieren kann.

Und deshalb sollte Georgs Backend der MySQL-Datenbank einen XML-Export bekommen. Dann lässt sich deine XML-Datei jederzeit mit einem Klick tagesaktuell erstellen und selbst Änderungen, die mehrere Datensätze betreffen, sind auf diesem Wege problemlos machbar. Ich verstehe also nicht, wo dein Problem liegt. :?

[[Mitglied Þors…]]

Die SQL-DB hat u.a. den Vorteil, dass mehrfach vorkommende Daten nur einmal gespeichert werden müssen. Es gäbe also wie schon erwähnt eine Tabelle mit mehreren Datenfeldern für die Schriften selbst, und dazu eine für die Entwerfer und eine für die Gießereien.

Das funktioniert in XML doch genau so:

<typokartei>
??<giessereien>
		<giesserei id="lum">
			<name>LUDWIG & MAYER</name>
			<adresse>
				<strasse>Hanauer Landstrasse 187-189</strasse>
				<ort>Frankfurt am Main</ort>
				<staat>Deutschland</staat>
			</adresse>
		</giesserei>
	</giessereien>
	<schriften>
		<schrift giesserei="lum">
			<name>Dominante</name>
			<schnitt>kursiv</schnitt>
			<erstguss>1959</erstguss>
			<schoepfer>
				<name>Johann Schweitzer</name>
				<adresse>
					<ort>Frankfurt am Main</ort>
					<staat>Deutschland</staat>
				</adresse>
			</schoepfer>
			<grade>
				<grad einheit="p">6</grad>
				<grad einheit="p">8</grad>
			</grade>
			<karte>dominante-kursiv.jpg</karte>
		</schrift>
		<schrift giesserei="lum">
			<name>Prägefest</name>
			<erstguss>1926</erstguss>
			<schoepfer>
				<name>Eduard Lautenbach</name>
				<adresse>
					<ort>Leipzig</ort>
					<staat>Deutschland</staat>
				</adresse>
			</schoepfer>
			<grade>
????		<grad einheit="p">12</grad>
????		<grad einheit="p">14</grad>
			</grade>
		</schrift>
??</schriften>
</typokartei>

Für die zentralisierte Eingabe wäre allerdings eventuell eine Datenbanklösung sinnvoll,

Keine Frage.

aus der nach Abschluss der Eingabe die Daten automatisch nach XMP exportiert und in die Dateien geschrieben werden.

… bzw. (zusätzlich) ein separates XML-Dokument erstellt wird, das die Kartei als Ganzes abbildet.

[[Mitglied Þors…]]

Und deshalb sollte Georgs Backend der MySQL-Datenbank einen XML-Export bekommen.

Das Wort, auf das es hier ankommt, ist »sollte«. Das Problem ist nur, dass in einem typischen Projekt niemand eine solche Exportfunktion bauen wird, wenn die zusammengehackte Anwendung erst mal auch so funktioniert. Wird es nicht von Anfang an richtig gemacht, wird das am Ende auch nichts mehr.

[Ralf Herrmann]

Ach Quatsch, bei einer so einfachem Aufbau ist das doch in 10 Minuten programmiert …

[[Mitglied Þors…]]

… ist das doch in 10 Minuten programmiert …

Dann drängt sich allerdings die Frage auf, warum man nicht gleich den so einfachen XML-zentrischen Ansatz verfolgt, sondern die Struktur in SQL dupliziert. Das (zusammen mit der Programmiererei in einer höheren Programmiersprache, um aus dem SQL was »vernünftiges« zu machen) dürfte nämlich erheblich länger als 10 Minuten dauern…

:?

Aber gut, wenn ein XML-zentrischer Ansatz hier so wenige Freunde findet, wie wär’s denn hiermit:

1. Verschlagwortung mit XMP (Sind wir uns einig, dass das so oder so geschehen sollte?)[/*:m:phy5q6fw]
   
2. Die so verschlagworteten (verschlagenen?) Bilder werden in einer XMP-fähigen Fotoverwaltungs-Webapplikation gezeigt[/*:m:phy5q6fw]
   
3. Fertig![/*:m:phy5q6fw]

Die Suche nach verschiedensten Suchbegriffen wird einfach von der schon eingebauten Funktionalität übernommen. Ist die Verschlagwortung getan, muss nichts weiter programmiert werden.

Georg hat die Wahl, ob er die Kartei einfach auf eine öffentliche XMP-fähige Fotowebsite lädt (den Werbeeffekt kann er mittels Wasserzeichen ja immer noch erzielen, durch die größere Reichweite vielleicht noch effektiver) oder eine entsprechende Weapplikation auf Bleisetzer.de oder wo auch immer installiert. (Es gibt da ja im OSS-Bereich schon einiges.)

Das große Fragezeichen ist natürlich die XMP-Unterstützung (insbesondere, was selbst definierte Felder angeht), sowohl bei existierenden Fotowebsites als auch entsprechender Software. Ich kann mir aber gut vorstellen, dass es so etwas bereits gibt oder bald geben wird. Eine kurze Recherche könnte sich lohnen.

[[Mitglied Cajo…]]

Das große Fragezeichen ist natürlich die XMP-Unterstützung (insbesondere, was selbst definierte Felder angeht), sowohl bei existierenden Fotowebsites als auch entsprechender Software. Ich kann mir aber gut vorstellen, dass es so etwas bereits gibt oder bald geben wird. Eine kurze Recherche könnte sich lohnen.

Zumindest hier im Forum arbeiten ja nicht wenige mit den Adobe-Programmen. In der Bridge ist XMP auf jeden Fall eingebaut (kein Wunder, XMP ist ja auch von Adobe), wie’s mit Stapelverarbeitung ausschaut müsste ich mal ausprobieren (hab ich noch nicht gebraucht).

[[Mitglied Alfo…]]

Sorry wenn ich jetzt meinen Senf auch noch dazu gebe: War schon lange nicht mehr im Forum und habe diesen Beitrag mal gelesen. Ich komme gerade aus einem 1-jährigen DB-Projekt und würde bei dieser Problemstellung auch XML wählen, es schreit für mich beinahe darnach. Þorsten hat die Vorteile ja alle schon genannt. Besonders erwähnenswert ist, dass wenn eine SQL-Datenbank steht und auch läuft (nach erheblich mehr als 10 Min.), wird niemand mehr einen XML-Export erstellen wollen. Wieso auch, es läuft ja gerade...? Auch ein Grund für XML: Wird die DB mal erneuert, erweitert oder auf eine andere Server-Umgebung transferiert, umprogrammiert oder was auch immer, vielleicht durch Leute die die Orginalversion nicht kennen, wäre mir ein XML Datensatz am liebsten da schön flexibel, klar strukturiert und innert Sekunden sogar für Laien einsehbar (öffnen im Browser), kontrollierbar und nachvollziehbar. Ein SQL-Ansatz müsste schon sehr gut dokumentiert sein damit er später nachvollziebar ist.

[Ralf Herrmann]

Diese Argumentation für XML gegen MySQL ist mir echt ein Rätsel. Wenn am Ende das Gleiche rauskommt, dann ist das doch keine Diskussion zwischen 2 verschiedenen Dingen, sondern nur zwischen den Wegen dahin. Und das hängt letztendlich von Georgs Möglichkeiten ab. Er hat einen MySQL-Datenbank und einen PHP-Programmierer parat stehen. Wenn er einen XML-Export will bekommt er den. Und bleibt jederzeit flexibel. Auch ein »Schreibe alle Bilder und Daten auf eine CD-ROM«-Paket oder ein »Generiere PDFs daraus« oder was auch immer wäre problemlos möglich. Warum soll er da manuell in einer Textdatei rumfummeln müssen?

Und die Datenbank ist auch in keinster Weise schwer nachvollziehbar. Jeder Font ist ein Datensatz und es gibt Querverweise zu Foundries (foundry_id), die dann in der Tabelle »foundries« stehen. Einfacher kann eine Datenbank nicht aufgebaut sein und im Vergleich zum Aufbau einer XML-Datei ist das Buchstäblich dasselbe in Grün.

Also vielleicht sollten wir Diskussion lieber auf die Frage lenken, was zur Pflege für Georg und seine Mitstreiter das günstigste wäre.

[[Mitglied Þors…]]

Diese Argumentation für XML gegen MySQL ist mir echt ein Rätsel. Wenn am Ende das Gleiche rauskommt,

Der Punkt, den CADtp, Alfons und ich rüber bringen wollten — mglw. erfolglos — war, dass es, langfristig gesehen, eben nicht aufs Gleich rauskommt, ob man eine Anwendung, wie man’s gerade kann, irgendwie zusammen kloppt oder ob man Technologien benutzt, die für den konkreten Anwendungsfall generell besser geeignet und langfristig einfacher zu pflegen sind.

Natürlich ist klar, dass Georg am Ende den Weg gehen wird, der ihm am einfachsten ist. Wir können ihn nicht zu seinem Glück zwingen und nur Denkansätze geben. Ich hoffe allerdings, dass die auch über dieses Projekt hinaus wirken. Wenn der eine oder andere Mitleser hier vor seinem nächsten Projekt eine Minute innehält und darüber nachdenkt, ob PHP+MySQL vielleicht doch nicht der Keil ist, der auf jeden Klotz gehört, haben wir schon was erreicht.

Und die Datenbank ist auch in keinster Weise schwer nachvollziehbar.

Na ja, wenn das in »keinster« Weise so ist, erübrigt sich wohl jede weitere Diskussion.

Also vielleicht sollten wir Diskussion lieber auf die Frage lenken, was zur Pflege für Georg und seine Mitstreiter das günstigste wäre.

Wenn ein XML-zentrische Ansatz, aus welchen Gründen auch immer, nicht akzeptabel oder praktikabel ist, stellt sich immer noch die Frage, ob man deswegen gleich eine PHP-MySQL-Anwendung programmieren muss.

Warum nicht einfach ein Wiki mit den Semantic Mediawiki- und Semantic Forms-Extensions und ein-zwei einfachen Templates?

[[Mitglied Alfo…]]

Warum soll er da manuell in einer Textdatei rumfummeln müssen?

Sowas macht man auch nicht manuell. Hier können sich seine php-Programmierer mit einer netten Oberfläche austoben. Aber, der Datensatz bleibt jederzeit kompakt und auch für Laien einsehbar.

Überlegung:

Warum (nur) eine Datenbank? Vielleicht möchte Georg am Schluss auch eine CDROM mit der er offline browsen kann und die er abgeben kann? :? Es handelt sich ja um relativ statische Daten (1500 Karteikarten) und sooo viele Änderungen wird es da ja nicht geben. Auf dem Server liegt dann die aktuelle Orginalversion (erweiterbar, lesen/schreiben der xml Datei z.B. mit php und verlinkt mit seiner Homepage) und ab und zu wird eine CDROM Version mit dem aktuellen Stand gemacht (Kopie der xml Datei auf CDROM und wird z.B. mit Javascript gelesen und nett im Browser dargestellt, sollte glaube ich gehen)

[[Mitglied Alfo…]]

Warum nicht einfach ein Wiki mit den Semantic Mediawiki- und Semantic Forms-Extensions und ein-zwei einfachen Templates?

Ohh, sehe gerade den Wiki-Ansatz. Kenne das nicht aber scheint mir sehr interessant zu sein. Eine DB braucht man ja um Daten zu verwalten (eine DB soll leben) und hier haben wir ja eher statische Daten.

[[Mitglied Blei…]]

Eine neue Information für Euch:

Ein guter Freund und Kollege hat mir einen Zugang zu Server und Software von Fotoware des gleichnamigen Herstellers gegeben. Die Bilddaten können dort im ITCP- oder XMP-Format abgelegt werden. Ein Editor mit einer vorbesetzten Textmaske baut er mir.

Es geht nun darum, die Informationen festzuhalten, die gemeinsam mit einem Bild gespeichert werden sollen. Nachfolgende Daten fielen mir so ein. Falls Ihr Ergänzungen habt: Jetzt ist der richtige Zeitpunkt dafür.

Schriftname (=Bildname)

Schriftgießerei

Erstgußjahr

Schriftenkünstler

Gruppe nach DIN 16518

Was seht Ihr noch als sinnvoll an?

Gruß

Georg

[[Mitglied Þors…]]

Ohh, sehe gerade den Wiki-Ansatz.

Ich habe zu Demozwecken einfach mal schnell ein Wiki aufgesetzt und mit den zwei Beispielkarten, die Georg auf seiner Seite hat, »gefüttert«.

Zumindest die Verschlagwortung könnte man so schon erledigen. Und wenn dann am Ende der Wille oder die Ressourcen fehlen, das Ganze dokumentenverwaltungsmäßig optimal XML-basiert zu machen, kann man es im Prinzip auch einfach weiter benutzen.

[[Mitglied Josh…]]

Warum soll er da manuell in einer Textdatei rumfummeln müssen?

Sowas macht man auch nicht manuell. Hier können sich seine php-Programmierer mit einer netten Oberfläche austoben. Aber, der Datensatz bleibt jederzeit kompakt und auch für Laien einsehbar.

Dieser Vorteil von XML ist keiner, weil niemand sich die XML-Datei anschauen können will oder muß. Und falls in der Datei auch die Daten verknüpft abgelegt sind, wird es sowieso schwierig bis unmöglich [für einen Laien] die Daten zu verstehen!

Eine MySQL-Datenbank und ihren Aufbau kann sich auch jeder einfach ansehen, nämlich durch ein entsprechendes Programm auf dem Server (z. B. phpmyadmin).

Und für CD-Roms, Anzeige über den Browser, Ausgabe als Buch oder was auch immer kann jeweils ein passendes Format erzeugt werden.

Der einzige „Vorteil“ von XML wäre, daß die Daten in Textdateien liegen und nicht in Binärdateien. Was bloß zum Tragen käme, wenn die Datenbank irgendwann aus irgendwelchen Gründen nicht mehr gelesen werden kann. Aber falls sich dieser Fall irgendwann abzeichnen sollte, macht man, schwupps, einen Sicherungs-Export (in welchem Format auch immer), und die Sache hat sich.

Binärdateien haben ihre Berechtigung! Textdateien gab's bereits, als MySQL geschaffen wurde. Solche Datenbanksysteme wurden entwickelt, weil sie schneller sind als das Dateisystem. Sie sind für Datenbankoperationen optimiert: strukturierte Datenspeicherung und -abfrage, Änderungen, Filter, Sortieren usw.

Datenbanksysteme, die ihre Daten in Textdateien (XML oder in irgendeinem anderen Format) speichern, müssen mit der Beschränkung arbeiten, kein für diese Aufgabe optimiertes Format zu benutzen, sondern eben einfach Textdateien.

Für gewisse Anwendungen sind XML-Dateien sicher sinnvoller als ein relationales Datenbanksystem, z. B. wenn sehr unterschiedliche Datensätze gespeichert werden müssen, die sich nicht in ein Schema quetschen lassen (etwa technische Daten von Fernsehern und Kaugummiautomaten). Aber bloß, weil das Binärformat später einmal veraltet sein könnte, Textdateien zu verwenden, halte ich für Unsinn. Ich speichere ja auch meine Bilder nicht als Textdateien, weil vielleicht in ferner Zukunft mal das PNG-Format nicht mehr gelesen werden kann!

Wie bei vielen Dingen in der EDV ist es aber auch bei dieser Diskussion so, daß meistens mit an Besessenheit grenzender Überzeugung von den Diskussionsteilnehmern eine Seite als die unbedingt bessere und die andere(n) als der größte Mist dargestellt wird! Die Wahrheit liegt natürlich irgendwo dazwischen. :D

[[Mitglied Blei…]]

Auf die Gefahr hin, etwas falsch verstanden zu haben, sicherheitshalber mein definitiver Standpunkt:

— Ich möchte das Angebot der Typokartei nur und ausschließlich auf www.Bleisetzer.de realisieren. Nirgends anders, auch nich auf einem wie immer gearteten Wiki. Ich bin auch ausdrücklich nicht damit einverstanden, daß die Bilder der Typokartei für ein anderes als das Archiv auf meiner Seite verwendet wird. Sollte dies nicht respektiert werden, gäbe es ein Problem. Ist dieser Wiki-Test öffentlich zugänglich? Was ist damit geplant, bitte?

— Das Problem des Editierens der Textinformationen zum Bild ist durch das Unternehmen fontware gelöst, die mich durch Server und Software unterstützen. Dies ist für mich deshalb so wertvoll, weil es der Grundrichtung entspricht, die ich seit Jahren vertrete: Ich versuche, Brücken zu schlagen zwischen der Tradition der Druckvorstufe, die ich repräsentiere und der digitalen Druckvorstufe von heute. Ich will kein Museum führen und fontware zeigt Sinn für Tradition durch aktive Unterstützung. Das ist bestens.

— Dem Rat, auf eine Signature am Bildrand zu verzichten und diese Information in die Bildtexte mit aufzunehmen, werde ich folgen. Danke dafür. Alle Bilder werden mit einer Lizenz zur freien Nutzung bei Nennung der Quelle versehen.

— Das Problem der Eingabe ist also gelöst. Was noch fehlen könnte, wären Informatione, die Ihr vorschlagt und die dort mit aufgenommen werden können.

— Offen ist nun also nur noch die Art des Aufbau des Angebotes für die Besucher. Nur darüber lohnt es sich noch zu diskutieren.

Gruß

Georg