Ideen für CK Updates

[Rince]

Hallo,

es wurde ja schon vor langer Zeit über Erweiterungen diskutiert.

Ich habe da so eine Idee. Ob sie ohne weiteres realisierbar ist???

Aber nun zur Idee:
Wie Daten wir und z.Z. ab? Nur über CDs.

Auf Wunsch deas Archivars : Der Austausch findet über eine Liste statt, in der sich diejenigen eintragen, welche per Post eine oder mehrere DB(s) austauschen wollen. Diese DB(s) wird/werden auf CD gebrannt und per Post untereinander ausgetauscht.

Nachteil, bis alle durch sind,kann es Wochen/Moante dauern, falls die Kette nicht durch die Gelben unterbrochen wird.

Was könnte man ändern?
In Zeiten von DSL und Flatrate könnte man ein Zusatztool/modul um CK programmieren, der sich das Verfahren von P2P-Netzen zu nutze macht.

1. Methode:
Über die bis jetzt vorhandenen Programme wrden komplette DBs verteilt.
Vorteil : Man benötigt keine neuen Tools
Nachteil : Man saugt ggf. massig an Daten, die man nicht braucht, oder schon hat.

2. Methode:
Es wird ein Tool entwickelt, welches direkt auf die DB(s) aufsetzt.
Bsp: Man kann sich die benötigte DB aussuchen und dann innerhalb der DB browsen um sich dann die benötigten Daten zu markieren. Hatt man sich sein Paket zusammengestellt, kann man die Übertragung starten.
Addon: Verteilte Übertragung wie bei den bekannten Programmen.

=> Die CD bräuchte man nur an "wenige" schicken, die dann die Daten übers Internet verteilen.

Was haltet Ihr von der Idee :engel:

mfG
Rince

P.S. Ich hoffe ich habe nicht zuviel geschrieben.

[Der_Archivar]

Hallo Rince !

Du solltest vielleicht die Überschrift abändern, bevor Oliver noch einen Herzinfarkt bekommt. Schreib doch sowas á la "Austausch von Datenbanken".

Ansonsten habe ich folgende Zeile nicht verstanden: "Wie Daten wir und z.Z. ab?" Zumindest weiss ich aus dem Kontext, was Du meinst.

Ansonsten habe ich zum Thema nichts zu sagen, das soll Oli machen.

Grüße vom Archivar

[CaptainEuro]

Die Idee finde ich gar nicht so schlecht. Ist natürlich eine Frage, ob dies machbar ist. Ich vote aber jedenfalls dafür :)

[Rince]

Original geschrieben von Der_Archivar
Hallo Rince !

Du solltest vielleicht die Überschrift abändern, bevor Oliver noch einen Herzinfarkt bekommt. Schreib doch sowas á la "Austausch von Datenbanken".



Konnte "leider" nur die Überschrift meines Postings ändern, fürs Thema ging es leider nicht.



Ansonsten habe ich folgende Zeile nicht verstanden: "Wie Daten wir und z.Z. ab?" Zumindest weiss ich aus dem Kontext, was Du meinst.

Ansonsten habe ich zum Thema nichts zu sagen, das soll Oli machen.

Grüße vom Archivar

Habe noch nen Satz eingefügt. Hoffe der Trifft Deine Zustimmung.
Olli hat mich bei meinen abgedrehetn Ideen eh nicht lieb.....:rolleyes:

mfG
Rince

[oliver4you]

...Olli hat mich bei meinen abgedrehetn Ideen eh nicht lieb.....:rolleyes:

Hi Lars - stimmt gar nicht :troesten: :)

Zu Deiner Frage:

Wir entwickeln bereits seit einigen Monaten parallel zum jetzigen CK eine Software, die Deinen Ideen ziemlich nahe kommt. Allerdings ist es im Moment noch etwas zu früh um näher darauf einzugehen, da das Konzept noch nicht vollständig ist und die Entwicklung sicherlich noch ein Jahr dauern wird.

Zu Methode 2:
- Hier sehe ich das Problem, dass es keine Vereinheitlichung gibt, wie Comics eingegeben werden sollen. Der eine Sammler gibt nur den Titel ein, eine anderer füllt alle Felder aus.
- Auch mit dem Datenschutz ist es so eine Sache. Wer möchte schon, dass ein Fremder Dateien auf der Festplatte durchwühlt.
- Zudem sollte auch eine gewisse Verfügbarkeit der Daten gewährleistet sein. Im MP3 Bereich sieht das natürlich anders aus, da immer einige hunderttausend User gleichzeitig online sind.

Trotzdem würde es uns (Artur und mich) schon interessieren, was die anderen Anwender von Deinen Ideen halten. Auch weitere Vorschläge können gerne angebracht werden. So nach dem Motto: Wie sollte die perfekte Software zum verwalten von Comics aussehen und was soll alles möglich sein? Auch abgedrehte Ideen sind ok :D

Grüßle

Oli

[Rince]

Original geschrieben von oliver4you
...Olli hat mich bei meinen abgedrehetn Ideen eh nicht lieb.....:rolleyes:

Hi Lars - stimmt gar nicht :troesten: :)


Hi,

da bin ich aber beruhigt. Hatte schon Panik



Zu Deiner Frage:

Wir entwickeln bereits seit einigen Monaten parallel zum jetzigen CK eine Software, die Deinen Ideen ziemlich nahe kommt. Allerdings ist es im Moment noch etwas zu früh um näher darauf einzugehen, da das Konzept noch nicht vollständig ist und die Entwicklung sicherlich noch ein Jahr dauern wird.

Super Super
Dazu kann ich nur dieses sagen:

:kupsherr: Oh Anbetungswürdiger
:laola: :laola: lasset uns ihm huldigen



Zu Methode 2:
- Hier sehe ich das Problem, dass es keine Vereinheitlichung gibt, wie Comics eingegeben werden sollen. Der eine Sammler gibt nur den Titel ein, eine anderer füllt alle Felder aus.


Das mit der Einheitlichkeit ist korrekt. Da gebe ich Dir Recht. Aber hier ist meine Einstellung lieber etwas als gar nichts. Abhilfe wäre hier ein automatisches Bewertungssystem welches Anhand der Anzahl der ausgefüllten Felder einen Wert zwischen 1-100% ausgibt. Anhand dieser Bewertung kann man entscheiden, ob man den Datensatz haben will, oder nicht.



- Auch mit dem Datenschutz ist es so eine Sache. Wer möchte schon, dass ein Fremder Dateien auf der Festplatte durchwühlt.


Korrekt hier gebe ich Dir Recht. Aber dieses könnte man durch das Programm unterbinden. Dem Programm kann man die Datenbank(en) die der Allgemeinheit zur Verfügung gestellt werden sollen angeben. Zugriff auf die DB(s) erfolgt nur übers Programm => kein Zugriff auf die Platte.
Ich denke jeder sollte sollte sich im Klaren sein, das er seinen PC durch die richtigen Mittel sichern muß, wenn er sich im Internet bewegt. Die Gefahr ist also auch ohne dieses Programm da.
Da nur Daten aus der DB getauscht werden, sollte die Gefahr von gefährlichen Code/Programmen auch gebannt sein.
Ich denke damit sollte das Problem erledigt sein
Also haben wollen :sabber:



- Zudem sollte auch eine gewisse Verfügbarkeit der Daten gewährleistet sein. Im MP3 Bereich sieht das natürlich anders aus, da immer einige hunderttausend User gleichzeitig online sind.


OK hier gebe ich Dir Recht, die Anzahl der jenigen, die sich dafür interessieren ist natürlich geringer als im MP3 und Film usw usw Bereich. :weinen::heul: Aber ich denke auch hier, lieber wenig als nichts. Umgehen könnte man dieses vielleicht durch einen "Hauptserver", der eine MasterDB hält, welche als Referenz genommen werden kann. Aber hier kann man sich ja auch etwas schlaueres überlegen, das bei nur einer DB der Traffik sehr hoch sein kann. Ich denke hier ist eine Sammlung von Ideen aller Anwender von Vorteil.

mfG
Rince

[Der_Archivar]

@Rince: Danke ! Ich hatte schon befürchtet, mich zu oberlehrerhaft anzuhören.




Wie sollte die perfekte Software zum verwalten von Comics aussehen und was soll alles möglich sein? [/B]

Was soll denn das heissen ? Die Software gibt´s doch schon ?!?

:)

[oliver4you]

Original geschrieben von Der_Archivar
Was soll denn das heissen ? Die Software gibt´s doch schon ?!?
:)
Welche Software kann schon von sich behaupten, 100% perfekt zu sein ;)

[tgmm]

Original geschrieben von oliver4you

Trotzdem würde es uns (Artur und mich) schon interessieren, was die anderen Anwender von Deinen Ideen halten. Auch weitere Vorschläge können gerne angebracht werden. So nach dem Motto: Wie sollte die perfekte Software zum verwalten von Comics aussehen und was soll alles möglich sein? Auch abgedrehte Ideen sind ok :D

Ich bin der meinung, daß der ComicKeeper für sich - wenn man von Kleinigkeiten, die das "Leben" schöner/angenehmer machen (wie: Kategorie für Autorenbilder, Export anhand eines Suchfilters, Erweiterung des Auktoren-Archivs bzw im Auktoren Heft-/Story-Eintrags), absieht - einen sehr hohen Perfektionsgrad erreicht hat.

Wie Rince jedoch schon am Anfang des Threads ausgeführt hat mangelt es jedoch noch im Bereich des Austauschs von Comic-Daten.

Das Hauptproblem hierbei besteht (wenn man von den fehlenden Standard-Einträgen absieht) in der fehlenden Eindeutigkeit der Comic-Bezeichnungen. Eine Titeleingabe ist nicht unbedingt eineindeutig (Schreibweisen etc.) und eine eindeutige ISBN-, ISSN-, oder EAN-Nummer gibt es nur für vielleicht 30% der Comics.

Ich bin gerade dabei hierzu ein größeres Dokument in denen ich die diversen Möglichkeiten des Datenaustausches mit Vor- und Nachteilen abprüfe zu verbrechen, aber im Großen und Ganzen läuft es auf 3 Ansätze heraus:

1. Eindeutiger Nummernkreis via Zentraldatenbank:
Wir erfinden das Rad neu und vergeben für jeden Comic eine eigene Nummer, die in einer Zentraldatenbank verwaltet wird.
Damit diese nachvollziehbar bleibt und vor allem im Voraus verwendbar ist, sollte sie sprechend sein. Mein Vorschlag wäre hierbei ein LL-VVV-SSS-HHHH-X (Also 2 Stellen für das Land/Sprache, 3 Stellen für den Verlag/Verlagslabel, 4 Stellen für das Heft (Nummer) und 1 Stelle für Varianten/Sonderausgaben)

Damit die Nummern korrekt verwendet werden können gibt es neben einem Nummern-Schlüssel in Textform auch eine CK-Beispielsdatenbank welche zu Identifikation (sofern nicht durch EAN eineindeutig) möglichst von jeder Serie das erste Exemplar enthält.

Sobald die Comics einen eineindeutigen Schlüssel haben ist eine gezielte automatische Distribution von Einzelheftinformationen möglich.

2. Zentraldatenbank aber "Teile und Herrsche"
Es findet i.A. kaum ein echter Datenaustausch zwischen Usern sondern eher ein Abgleich mit der "Zentraldatenbank" von rmordico statt. Diese ist inzwischen so groß, daß sie eigentlich wirklich nur noch per CD verteilt werden kann (selbst mit DSL und flatrate).
Es stellt sich nur die Frage ob für den User diese Größe wirklich wünschenswert ist. Brauche ich die ganze Datenbank wenn ich nur die neuen Hefte seit der letzten Distribution einpflegen will. Und selbst wenn ich die letzte Distribution nicht hatte - brauche ich das DC-Universum wenn ich Spiderman sammle? In meinen Augen ist mir dann sogar das komplette Marvel-Universum (mit Xmen, Thor und Captain America) zuviel.

3. Web-Interaktivität mit Einzel-Comics
Es gibt ein Package (ähnlich wie die winamp-Skins) bestehend aus einer Textdatei (XML oder z.B. mein Format2) und der Titelbild-Datei welches genau 1 Comic enthält. Dieses kann gezielt in ein beliebiges Verzeichnis der eigenen CK-Datei importiert und daraus exportiert werden. Diese Packages enthalten nur Informationen zum Comic (kein Händler, kein Einkaufsdatum, kein Status, keine erweiterten Autorendaten
etc)
Ausgewählt werden diese Packages interaktiv anhand von Thumbnails bzw anderen Angaben von einer Webseite, wo sie dann heruntergeladen werden.
Für erweiterte Autorendaten, Händleradressen, und Verlagskontakte sollte der Import von VCards (evtl. Normkonform geringfügig erweitert) ermöglicht werden.

ähm mein Wecker klingelt... Ich muß aufstehn... :)

cuagn Thomas

[Rince]

Hi,

im Großen und Ganzen stimme ich Dir zu.

zu 1.) +++ nur so kann es sein. Die Bezeichnung eines Comics muß eindeutig sein. Wie?? Das ist die Frage.
Dein Schema hat einen Nachteil (?) oder wirft eine Frage auf, wie wird diese Nummer generiert?`Hier wäre ein Automatismus super. Ich würde diese Nummer noch um einen Index, der von der Zentralen DB vergeben wird, erweitern. Dein Teil der Nummer wird automatisch com CK vergeben. Durch Eingabe der Daten wird die Bezeichnung generiert. ALso, als Bsp, ich gebe ein Comic ein, dort gebe ich die ich die benötigten Werte ein. Durch die Eingabe der Werte wird, im CK für die Entsprechenden Daten der Schlüssel in den Tabellen gesucht und zusammengesetzt. Vorraussetzung dafür sind natürlich Standard-Einträge, die im CK implementiert sind. Werden Daten nicht eingegeben wird ein spezieller Platzhalter für den eigentlichen Wert eingegeben. Die fehlenden Werte könnten dann von jemanden direkt auf dem Server nachgetragen werden, worurch der Schlüssel komplettiert wird. Werden die Daten nun zum Zentralen Server geschickt, werden diese in die DB einsortiert und bekommen einen Index, so können mehrere Comics eindeutig identifiziert werden. Als Addon wäre hier vielelicht noch ein Prozentwert am Ende, der angibt, wie komplett das Comic eingepflegt wurde.

zu 2.) Jepp, sehe ich genauso, die Interessen sind unterschiedlich. Hier würde es IMHO Sinn machen Auswahlmöglichkeiten zu bieten.

zu 3.) siehe dazu meine Ideen zu 1.)
Ich denke hier sollte man die Daten nicht beschneiden. Es sollte hier IMHO die Möglichkeit geboten werden das man die Felder die man benötigt antackert. So kann man dann die Daten saugen, die man möchte.
Das würde IMHO mehr Sinn machen, als Lückenhafte Daten zu saugen, die man ggf. umständlich komplettieren muß.

So, ich hoffe ich habe Euch nicht allzu gelangweilt.

[oliver4you]

Zum Thema Identifizierung:

Ein eindeutiger Schlüssel für jedes Heft ist beim Austausch einzelner Daten über das Internet sicherlich unabdingbar. Dann wäre beispielsweise auch der automatische Preisabgleich relativ einfach möglich; vorausgesetzt jemand hat die Daten dazu. Wie dieser Schlüssel aussieht, ist für die Entwicklung eigentlich egal - er muss nur eindeutig sein.

Nochmals zu dem von tgmm vorgeschlagenen Format LL-VVV-SSS-HHHH-X Sollte bei SSS nicht ein Kürzel (z.B. BTG für Batgirl) stehen?

LL : 2 Stellen Land/Sprache
VVV : 3 Stellen für den Verlag/Verlagslabel
SSS : ?
HHHH: 4 Stellen für Nummer
X : 1 Stelle für Varianten/Sonderausgaben)

Wenn das so angedacht ist, dann kann der Keeper von sich aus so ein Kürzel leider nicht automatisch erstellen. Hier wäre dann Handarbeit angesagt. Auch wäre ein dreistelliges Kürzel wohl nicht ausreichend.

Was meint ihr?

[Der_Archivar]

Finde die Idee mit dem Kürzel super.

SSS wird für die Angabe der Serie stehen.

Gruß Archi

[Rince]

Original geschrieben von oliver4you
Zum Thema Identifizierung:

Wenn das so angedacht ist, dann kann der Keeper von sich aus so ein Kürzel leider nicht automatisch erstellen. Hier wäre dann Handarbeit angesagt. Auch wäre ein dreistelliges Kürzel wohl nicht ausreichend.

Was meint ihr?

Hi,

wäre ein Automatismus nicht mit meiner unter 1.) beschriebenen Methode möglich?
Jetzt etwas kürzer (deutlicher)

Es existieren Standardwerte. Diese sind für die verschiedenen Datenfelder in Tabellen hinterlegt.
Dadurch sind sie durch ihren Indexwert in der Tabelle eindeutig identifizierbar.
Wird nun ein Feld mit einem Standardwert belegt, kann ein eindeutiger Schlüsselteil generiert werden.
Alle Felder werden so automatisch ausgefüllt und die Schlüsselteile automatisch generiert.
=> IMHO müßte so ein automatisches Generieren des ganzen Schlüssels möglich sein.

Problem:
Wenn mehrere User das gleiche Comic mit den gleichen Werten eingeben, erzeugen Sie einen gleichen Schlüssel. Dieser Schlüssel wird bei einem Upload in die zentrale DB um einen Index, der von der zentralen DB vergeben wird ergänzt.
Durch den von der Zentralen DB vegebenen letzten Teil ist die dem Comic zugeordnete Nummer eindeutig.

Habe ich etwas vergessen?

mfG
Rince

[tgmm]

Original geschrieben von Der_Archivar
Finde die Idee mit dem Kürzel super.

SSS wird für die Angabe der Serie stehen.

Gruß Archi
Genau, um halb Sechs in der Früh darf einem doch mal so ein Flüchtigkeitsfehler passieren. :)

Wichtig erscheint mir jedoch vor allem bei meinem Konzept, daß der Schlüssel (sofern es die Serie schon gibt) auch in die Zukunft reicht.
Ich habe also schon, ohne die Zentraldatenbank zu bemühen, den Schlüssel für den Manga 3x3 Augen Band 28 obwohl dieser frühestens 2004 bei Carlsen erscheint.

Oder noch bösartiger - sobald ich z.B. anhand des Coverbildes eines Heftes die Serie (und damit den Serienschlüssel) identifiziert habe kann ich jedes Heft eineindeutig beschreiben ohne mich um etwaige Schreibweisen zu kümmern.
Ich brauche mir keine Gedanken mehr zu machen ob die Serie in offizieller Schreibweise "XMen neu", "x-Men (neu)" oder gar "X-Men - neu" heißt.

Der einzige Nachteil an meinem Konzept besteht - wie Oliver richtig erkannt hat -, daß der Schlüssel nur eingeschränkt vom ComicKeeper erstellt werden kann (höchstens Heftschlüssel aus in der Sammlung angegebenen Serienschlüssel). Der Schlüssel muß wenigstens als Serienschlüssel zentral vergeben/verwaltet werden und von jedem Benutzer von Hand eingegeben werden.
Wenn er es allerdings richtig macht (sprich den richtigen Schlüssel eingibt), braucht er nur noch den Schlüssel (und ev. die Anzahl) einzugeben und den Rest macht dann via Internet (Web-Service) das System...

cuagn Thomas

[tgmm]

Original geschrieben von Rince
[...]
zu 3.) siehe dazu meine Ideen zu 1.)
Ich denke hier sollte man die Daten nicht beschneiden. Es sollte hier IMHO die Möglichkeit geboten werden das man die Felder die man benötigt antackert. So kann man dann die Daten saugen, die man möchte.
Das würde IMHO mehr Sinn machen, als Lückenhafte Daten zu saugen, die man ggf. umständlich komplettieren muß.


Sorry, aber Du hast mich anscheinend nicht ganz verstanden.
Meine 3 Varianten waren unterschiedliche Ansätze, wie man das Problem der Distribution in Verbindung mit der Tatsache, daß es Probleme mit der eineindeutigen Beschreibung eines Comics gibt, angehen kann. (Teilweise alternativ gedacht)

Die 3. Variante ging davon aus, daß der (Daten-)Anbieter irgendwo Webspace besitzt und seine Comic-Daten zur Verfügung stellen will.
In diesem Falle kann/muß man ebenfalls davon ausgehen, daß der Anbieter keine Möglichkeit hat (eigene) Programme auf seinem Webserver laufen zu lassen. Somit ist beschränkt sich die Auswahl des Daten-Konsumenten darauf: Will ich die Daten eines Comics oder nicht?

Für die Anwendung stell dir folgendes Szenario vor: Ich habe mir im Urlaub die ersten 4 Bände der Albumserie "Rubine" gekauft. Anstatt jetzt eine riesige Album-Datenbank herunterzu laden (in der Hoffnung die Alben dort zu finden) oder auf die CD mit den Zentraldaten zu warten, finde ich (ok bei Rubine schon über den Titel - sonst über ein Cover-Thumbnail) die richtigen 4 Packages, lade sie herunter und importiere sie in ein Verzeichnis meiner Wahl (egal ob Alben->Epsilon oder Alben->Krimis). 5 Wochen später kommt der 5. Band auf den Markt und ich lade nicht wieder eine hoffentlich aktualisierte Album-Datenbank herunter sondern nur das 5. Package.

Zu den Einschränkungen folgender Hinweis: Sobald ein Autor, Händler oder Verlag einmal in die CK-Datenbank eines Users eingegeben wurde ist z.Z. eine Aktualisierung der erweiterten Daten (Anschrift, Kontakt, Bild etc.) via Import nicht mehr möglich. Warum soll man diese (erweiterten) Daten dann überhaupt noch in einem Einzelheft-Package mitschleppen? Es ist doch dann viel sinnvoller wenn die Pflege dieser Daten gezielt über ein Spezielles Package (hier bietet sich IMHO die vCard an, da jeder noch so kleine Händler sie {z.B. über Outlook-Express} selbst erstellen kann) durchführen kann.
Auch sind Status und Lagerort eines Comics für den Importeur der Daten vollkommen uninteressant während Zustand und Bewertung, Händler, Einkaufsdatum und Einkaufspreis höchstens dann von Interesse sind, wenn genau dieses Comic-Heft zum Verkauf steht.

Die Größe der Packages hängt weitgehend von der Größe der Bilddatei ab und dürfte bei ca 50kB pro Heft liegen

Ich hoffe ich habe nun alle Klarheiten über meinen 3. Vorschlag beseitigt :)

cuagn Thomas

[oliver4you]

Original geschrieben von Rince
... Es existieren Standardwerte. Diese sind für die verschiedenen Datenfelder in Tabellen hinterlegt.
Dadurch sind sie durch ihren Indexwert in der Tabelle eindeutig identifizierbar.
Wird nun ein Feld mit einem Standardwert belegt, kann ein eindeutiger Schlüsselteil generiert werden.
Alle Felder werden so automatisch ausgefüllt und die Schlüsselteile automatisch generiert.
=> IMHO müßte so ein automatisches Generieren des ganzen Schlüssels möglich sein.

Ahhhh, alles klar! Dir geht es um die Identifikation der Daten, die bereits zu dem Comic eingegeben wurden. Sozusagen ein "Daten-Zustand" des Comics. Hier könnte der Keeper natürlich den Schlüssel automatisch generieren :) .

Wie identifizieren wir aber das Heft eindeutig. Ich denke in diese Richtung gehen die Überlegungen von tgmm. Einen Schlüssel automatisch zu generieren, der auf der Serie und dem Titel des Heftes basiert, würde einer Software schon mehr Schwierigkeiten bereiten.

@tgmm
IMHO sollte der Anwender selbst auswählen können, welche Daten er aus dem Package eines Comics importieren möchte. Es gibt sicherlich User, die ihre Sammlung nur über Daten aus dem Internet verwalten wollen; da sollte ein Package so komplett wie möglich sein.

[Der_Archivar]

Zum Thema "Den Schlüssel zur Identifizierung eines Heftes muß man von Hand eingeben":

Also ganz ehrlich und objektiv gesehen:

Wer es nicht schafft, zu einem Neueintrag eines Comics die 13 Ziffern des Schlüssels selbst einzugeben, sollte vielleicht auch die restlichen Daten zum Heft und der Story weglassen.

Archi

[tgmm]

Original geschrieben von oliver4you

@tgmm
IMHO sollte der Anwender selbst auswählen können, welche Daten er aus dem Package eines Comics importieren möchte. Es gibt sicherlich User, die ihre Sammlung nur über Daten aus dem Internet verwalten wollen; da sollte ein Package so komplett wie möglich sein.

Ich stimme mit Dir darin überein, daß die Daten über ein Heft so komplett wie möglich sein sollten. (Von den Zustandsbeschreibungen eines speziellen Heftes welches nicht einmal zum Verkauf ansteht mal abgesehen).

Anders sieht es jedoch aus, wenn es um die erweiteren Informationen zu einem Autor geht. (Portrait, Lebensdaten, Anschrift, Kontakt, Informationen zu Werdegang und Auszeichnungen etc.)

Wenn ich z.B. die 11 Packages zur Albumserie "Tassilo" herunterlade, halte ich es für sinnvoller wenn ich 11 Packages zu je 30-50 kB (mit Comicdaten incl. Autoren-Namen und Coverbild, Rezensionen etc) herunter lade sowie seperat die 3 "vCards" der Texter und Zeichner (zu je 30-50 kB) sowie (sofern nicht von Asterix schon vorhanden) die vCard von Ehapa (2-3 kB) als wenn ich wegen der Portraits der Autoren 11 Packages zu je 150-200 kB (mit jeweils den gleichen Informationen zu Autoren und Verlag) herunterladen würde.

Gleichzeitig würde eine solche Redundanz bewirken, daß auf 10MB Webspace nur noch 50 Comics angeboten werden könnten statt ca 200 was widerum dem Package-Konzept (wegen mangelndem Angebot) den garaus bereiten würde.

cuagn Thomas

[oliver4you]

Original geschrieben von tgmm
... Wenn ich z.B. die 11 Packages zur Albumserie "Tassilo" herunterlade, halte ich es für sinnvoller wenn ich 11 Packages zu je 30-50 kB (mit Comicdaten incl. Autoren-Namen und Coverbild, Rezensionen etc) herunter lade sowie seperat die 3 "vCards" der Texter und Zeichner (zu je 30-50 kB) sowie (sofern nicht von Asterix schon vorhanden) die vCard von Ehapa (2-3 kB) als wenn ich wegen der Portraits der Autoren 11 Packages zu je 150-200 kB (mit jeweils den gleichen Informationen zu Autoren und Verlag) herunterladen würde.


Hm, stimmt; das macht Sinn!


Noch 'ne andere Sache:

Im Moment ist es ja so, dass man ein Comic sowohl als einzelnes Heft (das blaue Buch-Icon) als auch als Heft mit Story verwalten kann. Das hat schon oftmals zu Verwirrung bei den Anwendern geführt.

Was haltet ihr davon, wenn künftig jedes Heft immer mindestens eine Story in der Tabelle enthalten MUSS. Die Daten wären dann ebenfalls logisch getrennt. So würden Informationen wie beispielsweise "Einbandart", "Format", "Preis", "Zustand" dem Heft zugeordnet werden, während die Story dann Infos zu "Autor", "Darsteller", "Geschichte" usw. enthält.

[Rince]

Original geschrieben von tgmm


Sorry, aber Du hast mich anscheinend nicht ganz verstanden.
Meine 3 Varianten waren unterschiedliche Ansätze, wie man das Problem der Distribution in Verbindung mit der Tatsache, daß es Probleme mit der eineindeutigen Beschreibung eines Comics gibt, angehen kann. (Teilweise alternativ gedacht)

Die 3. Variante ging davon aus, daß der (Daten-)Anbieter irgendwo Webspace besitzt und seine Comic-Daten zur Verfügung stellen will.
In diesem Falle kann/muß man ebenfalls davon ausgehen, daß der Anbieter keine Möglichkeit hat (eigene) Programme auf seinem Webserver laufen zu lassen. Somit ist beschränkt sich die Auswahl des Daten-Konsumenten darauf: Will ich die Daten eines Comics oder nicht?


Hi,

irgendwie reden wir aneinander vorbei.
Es geht mir um die Erzeugung der Schlüssel.
Der Schlüssel ist so aufgebaut, wie Du es beschrieben hast, nur wird dieser Schlüssel aus den im CK vorhandenen Standardwerten erzeugt. Das ist die ganze Idee. Da es bei der Eingabe in den CK an verschiedenen lokalen Installationen zu identischen Schlüsseln kommen kann, die aber lokal mangels Datenaustausch mit anderen nicht zu Gewicht fallen, wird erst beim Austausch mit einem Zentralen Server ein weiterer eindeutiger Schlüssel, der diesem Comic zugeordnet ist lokal und Serverseitig angehängt. Damit es nicht zu kompliziert ist, wäre hier die laufende Nummer aller Comics mit diesem Schlüssel logisch. Damit wäre die Generierung eines eindeutigen Schlüssels gegeben.
Als Option wäre eine zusätzliche Stelle im Schlüssel denkbar, die die Volständigkeit des Datensatzes angibt. Vielleicht eine 3-Stellige Zahl, welche den Prozentwert der Vollständigkeit angibt.
Diese Idee bezieht sich nur auf die Schlüsselgenerierung und nicht auf auf den Datenaustausch. Dazu später.



Für die Anwendung stell dir folgendes Szenario vor: Ich habe mir im Urlaub die ersten 4 Bände der Albumserie "Rubine" gekauft. Anstatt jetzt eine riesige Album-Datenbank herunterzu laden (in der Hoffnung die Alben dort zu finden) oder auf die CD mit den Zentraldaten zu warten, finde ich (ok bei Rubine schon über den Titel - sonst über ein Cover-Thumbnail) die richtigen 4 Packages, lade sie herunter und importiere sie in ein Verzeichnis meiner Wahl (egal ob Alben->Epsilon oder Alben->Krimis). 5 Wochen später kommt der 5. Band auf den Markt und ich lade nicht wieder eine hoffentlich aktualisierte Album-Datenbank herunter sondern nur das 5. Package.


Meine Idee des Austausches schließt einen zwingenden Austausch der kompletten DB aus, das das Wahnsinn wäre. Warum soll ich mit 1000den Comics meine lokale DB zumüllen, wenn mich nur 10 neu interessieren.

Meine Idee hierzu:
Ich frage die Zentrale DB ab. Teile mein(s) Wunschcomic(s) der DB mit und lasse mir alle zutreffenden Comics anzeigen. Aufgrund des zusätzlichen Wertes, der die Vollständigkeit angibt, suche ich mir das benötigte Comic heraus und und lege es in einen "Warenkorb". Nach beendigung der Auswahl importiere ich mir meine Daten in meine lokale DB.
=> kein kompletter Austausch nötig.
Es ist desweitren jedem freigestellt Daten auf seiner Homepage (einzeln exportierte Comics) zum Download anzubieten. Diese Daten lassen sich einzeln downloaden und importieren.




Zu den Einschränkungen folgender Hinweis: Sobald ein Autor, Händler oder Verlag einmal in die CK-Datenbank eines Users eingegeben wurde ist z.Z. eine Aktualisierung der erweiterten Daten (Anschrift, Kontakt, Bild etc.) via Import nicht mehr möglich. Warum soll man diese (erweiterten) Daten dann überhaupt noch in einem Einzelheft-Package mitschleppen? Es ist doch dann viel sinnvoller wenn die Pflege dieser Daten gezielt über ein Spezielles Package (hier bietet sich IMHO die vCard an, da jeder noch so kleine Händler sie {z.B. über Outlook-Express} selbst erstellen kann) durchführen kann.
Auch sind Status und Lagerort eines Comics für den Importeur der Daten vollkommen uninteressant während Zustand und Bewertung, Händler, Einkaufsdatum und Einkaufspreis höchstens dann von Interesse sind, wenn genau dieses Comic-Heft zum Verkauf steht.


Ok ist einsehbar. Aber warum VCards? Wenn ich mich recht erinnere gab es bei denen doch eine Sicherheitslücke. Oder ist sie schon gefixed?
Eine weitere Idee war die Möglichkeit einzelne Datenfelder anzuklicken, deren Daten man importieren möchte. OK, hierzu müßte ein nachträglicher Update möglich sein. Wie stellst Du Dir jetzt ein Package vor?
Irgendwie muß doch darüber ein Update des vorhandenen datensatzes möglich sein. Ich denke hier verfolgen wir beide ähnliche Ideen.



Die Größe der Packages hängt weitgehend von der Größe der Bilddatei ab und dürfte bei ca 50kB pro Heft liegen

Ich hoffe ich habe nun alle Klarheiten über meinen 3. Vorschlag beseitigt :)

cuagn Thomas

Wie Du an meinen Ideen sehen konntest denken wir beides an das gleiche

mfG
Lars

[Rince]

Original geschrieben von oliver4you


Ahhhh, alles klar! Dir geht es um die Identifikation der Daten, die bereits zu dem Comic eingegeben wurden. Sozusagen ein "Daten-Zustand" des Comics. Hier könnte der Keeper natürlich den Schlüssel automatisch generieren :) .

Wie identifizieren wir aber das Heft eindeutig. Ich denke in diese Richtung gehen die Überlegungen von tgmm. Einen Schlüssel automatisch zu generieren, der auf der Serie und dem Titel des Heftes basiert, würde einer Software schon mehr Schwierigkeiten bereiten.


Jupp einer versteht mich B^) Aber leider nur Teilweise.
Dreh und Angelpunkt sind die Standardwerte. Da über sie der Schlüssel generiert wird, müssen die Werte sehr komplett sein und auch Verlage und Serien beinhalten.
Vorteil : automatische Generierung möglich
Nachteil : Standardwerte müßten bei neuen Serien ereitert werden können. Die einzige Möglichkeit die ich hier sehe wäre das Einspielen direkt über den Zentralen DB-Server. Der checkt bei einen Connect die Aktualität der lokalen Standardwerte.



@tgmm
IMHO sollte der Anwender selbst auswählen können, welche Daten er aus dem Package eines Comics importieren möchte. Es gibt sicherlich User, die ihre Sammlung nur über Daten aus dem Internet verwalten wollen; da sollte ein Package so komplett wie möglich sein.

Jupp, so wie ich mich kenne, würde ich die Grunddaten eingeben, aber die Stories, Autoren usw auslassen. Die würde ich dann per Internet einbinden. Siehe dazu auch meine Idee zum Datenaustasch. (Anklicken der gewünschten Daten)

mfG
Lars

[Rince]

Original geschrieben von Der_Archivar
Zum Thema "Den Schlüssel zur Identifizierung eines Heftes muß man von Hand eingeben":

Also ganz ehrlich und objektiv gesehen:

Wer es nicht schafft, zu einem Neueintrag eines Comics die 13 Ziffern des Schlüssels selbst einzugeben, sollte vielleicht auch die restlichen Daten zum Heft und der Story weglassen.

Archi

Hi,

theoretisch sehe ich das auch so. Aus leidvollen beruflichen Erfahrungen, ich betreue Server/User in einem größeren Netzwerk, kann ich Dir sagen, das man leider bei vielen Leuten nicht viel vorraussetzen darf. (Nicht negativ gemeint, aber leider setzen sich nicht allzuviele Leute mit ihren Arbeitsgeräten auseinander. Ebenso sitzt der Fehler in vielen Fällen vor dem Monitor.)
Um also viele Probleme von Anfang an ausschließen zu können, spricht vieles für eine automatische Vergabe.

mfG
Lars

[tgmm]

Original geschrieben von Rince


Hi,

irgendwie reden wir aneinander vorbei.
Es geht mir um die Erzeugung der Schlüssel.
Der Schlüssel ist so aufgebaut, wie Du es beschrieben hast, nur wird dieser Schlüssel aus den im CK vorhandenen Standardwerten erzeugt. Das ist die ganze Idee. Da es bei der Eingabe in den CK an verschiedenen lokalen Installationen zu identischen Schlüsseln kommen kann, die aber lokal mangels Datenaustausch mit anderen nicht zu Gewicht fallen, wird erst beim Austausch mit einem Zentralen Server ein weiterer eindeutiger Schlüssel, der diesem Comic zugeordnet ist lokal und Serverseitig angehängt. Damit es nicht zu kompliziert ist, wäre hier die laufende Nummer aller Comics mit diesem Schlüssel logisch. Damit wäre die Generierung eines eindeutigen Schlüssels gegeben.
Als Option wäre eine zusätzliche Stelle im Schlüssel denkbar, die die Volständigkeit des Datensatzes angibt. Vielleicht eine 3-Stellige Zahl, welche den Prozentwert der Vollständigkeit angibt.
Diese Idee bezieht sich nur auf die Schlüsselgenerierung und nicht auf auf den Datenaustausch. Dazu später.


Wir reden anscheinend wirklich aneinander vorbei, da Du unbedingt die 3 verschiedenen Ansätze miteinander vermengen willst. Da du am Konzept der Packages nicht interessiert bist (die brauchen nähmlich keinen Schlüssel, da die Auswahl von einem stinknormalen Webserver {z.B. über ein Cover-Thumbnail} erfolgt) vergessen wir erst mal Deine Äußerungen zu den Packages und gehen zu der Key-gesteuerten, automatischen Distribution via Webservice bzw. Aktive-X o.ä. über.

Erst einmal 2 Fragen:

1. Woher nimmst du Standardwerte für einen Hefttitel?
Wir haben es ja noch nicht einmal geschafft, uns auf einen Standard für so einfache Dinge wie Genre und Heftformat zu einigen. (Wenn der letzte Benutzer begriffen hat, daß er z.B. statt "XMen (neu)" nur "X-Men neu" schreiben darf, dann brauchen eigentlich keine Schlüssel mehr :) )

2. Was soll der lokale Schlüssel?
Ich vermute Du willst Ihn verwenden um die Serien zu verwalten, zu denen es bisher keinen zentralen Serienschlüssel gibt. Aber dies wäre IMHO zu spät und tödlich, da erst einmal die große Diskussion ausbrechen würde ob nun die Serien "XMen (superneu)" und "X-Men super" identisch seien, bis der neue Zentral-Serienschlüssel definiert ist und dann (händisch) aus dem lokalen Schlüssel der Einheitsschlüssel gemacht werden müßte.

Man könnte natürlich (frei nach dem Film "Die Lady und ihre Gauner") auch eine automatische Korrekturliste verteilen mit der alle ungewollten Schreibweisen in die "Einheitsschreibweise" umgewandelt würden. Sollte aber später eine ungewollte Schreibweise für eine neue Serie zur Einheitsschreibweise werden hätten wir ein Problem.

Vom Vollständigkeit-Schlüssel halte ich verhältnismäßig wenig, da er eigentlich nur treffen würde wenn der Datenaustausch automatisch bidirektional (also auch Daten werden automatisch in die Zentraldatenbank importier) verlaufen würde. Ein solcher Automatismus (ohne redaktioneller Einflußnahme) würde aber entweder den schnellsten Benutzer (egal ob Daten richtig oder nicht) präferieren oder innerhalb kürzester Zeit die Zentraldatenbank korrumpieren.
Außerdem müßte solch ein Schlüssel genau beschreiben welche Informationen vorrätig sind und welche nicht (eine Prozentangabe ist niedlich aber sinnlos).




Meine Idee des Austausches schließt einen zwingenden Austausch der kompletten DB aus, das das Wahnsinn wäre. Warum soll ich mit 1000den Comics meine lokale DB zumüllen, wenn mich nur 10 neu interessieren.

Meine Idee hierzu:
Ich frage die Zentrale DB ab. Teile mein(s) Wunschcomic(s) der DB mit und lasse mir alle zutreffenden Comics anzeigen. Aufgrund des zusätzlichen Wertes, der die Vollständigkeit angibt, suche ich mir das benötigte Comic heraus und und lege es in einen "Warenkorb". Nach beendigung der Auswahl importiere ich mir meine Daten in meine lokale DB.
=> kein kompletter Austausch nötig.
Es ist desweitren jedem freigestellt Daten auf seiner Homepage (einzeln exportierte Comics) zum Download anzubieten. Diese Daten lassen sich einzeln downloaden und importieren.


Ich sehe das im Prinzip ähnlich - nur ist das nicht das, was wir momentan mit der CD machen.

Das Problem besteht nur darin, daß der Betrieb einer Zentraldatenbank (wenn er nicht bastlermäßig via DynDNS und hart an der AGB des Telekommunikations-Netzanbieters vorbei abgewickelt wird) ca 1000 Euro im Jahr kostet. (Rechner-Hardware und Software-Lizenzen {zwischen 20-50T Euro} mal nicht mitgerechnet)

Eine solche Investition ist für viele unerschwinglich (Laut einem Gespräch mit Oliver sucht tooligan noch einen Sponsor der bereit ist, die notwendige Infrastruktur für mehrere Jahre zur Verfügung zu stellen)

Die große Gefahr besteht außerdem darin: Wer zahlt, der bestimmt.
Und dies kann dann dazu führen, daß auf einmal bestimmte Serien, Verlage oder im Handel vergriffene Hefte etc nicht mehr über die CK-Zentraldatenbank verwaltet werden können.

Schließlich und endlich steht und fällt dann jeder Datenaustausch mit der Betriebsbereitsschaft der Zentraldatenbank - für mich eine grausige Vorstellung.



Ok ist einsehbar. Aber warum VCards? Wenn ich mich recht erinnere gab es bei denen doch eine Sicherheitslücke. Oder ist sie schon gefixed?
Eine weitere Idee war die Möglichkeit einzelne Datenfelder anzuklicken, deren Daten man importieren möchte. OK, hierzu müßte ein nachträglicher Update möglich sein. Wie stellst Du Dir jetzt ein Package vor?
Irgendwie muß doch darüber ein Update des vorhandenen datensatzes möglich sein. Ich denke hier verfolgen wir beide ähnliche Ideen.



Ich habe vCards vorgeschlagen als bekanntes Standardformat für den Austausch von Kontaktadressen. Genau so gut könnte es auch eine XML-Datei oder etwas ganz anderes sein.

Die Sicherheitslücke bestand im automatischen Import der vCards in div. Outlook bzw. OutlookExpress Versionen. Aber wir wollen die Informationen gar nicht in einen Mailer sondern in den ComicKeeper importieren.

Der Vorteil der vCards (und damit der Grund warum ich sie überhaupt für den Datenaustausch via normaler Webseite vorgeschlagen hatte) besteht darin, daß sie eigentlich von jedem Händler und jedem independent Selbstverlag einfach selbst erstellt werden kann.

Und das Package (ich sags zum dritten Mal) ist ein alternativer Lösungsansatz Daten einzelner Hefte ohne Zentraldatenbank und ohne spezieller Serverextensions oder anderer Dinge, die ein T-Online-, Web.de- oder AOL-Kunde nicht zur Verfügung hat anbieten zu können.

Da der Anbieter i.A. keine Möglichkeit hat eigene Programme oder gar Datenbanken auf seinen 10MB Webspace zu verwenden muß sich die Auswahl der Elemente bei diesem Ansatz weitgehend auf alles oder nichts beschränken. Was der Daten-Konsument dann mit den Daten anfängt, die er bekommen hat ist natürlich seine Sache.

Ich hoffe nun sind alle klarheiten beseitigt und ich kann die Studie, welche die Vor- und Nachteile der einzelnen Distributionswege zusammenstellt, fertigstellen.

cuagn Thomas

[tgmm]

Original geschrieben von Rince

Jupp einer versteht mich B^) Aber leider nur Teilweise.
Dreh und Angelpunkt sind die Standardwerte. Da über sie der Schlüssel generiert wird, müssen die Werte sehr komplett sein und auch Verlage und Serien beinhalten.
Vorteil : automatische Generierung möglich
Nachteil : Standardwerte müßten bei neuen Serien ereitert werden können. Die einzige Möglichkeit die ich hier sehe wäre das Einspielen direkt über den Zentralen DB-Server. Der checkt bei einen Connect die Aktualität der lokalen Standardwerte.


Ich habe mir gerde einen neuen Druckertreiber geladen und dabei ist mir (hoffentlich) der Groschen gefallen, wie Du dir die "halbautomatische" Schlüsselermittlung vorstellst. (Bitte korrigiere mich)

Wenn der Benutzer einen "Serienordner" (nur eine Serie im Ordner) oder ein Heft in einem "Sammelordner" (mehrere Serien in einem Ordner bzw. Verlagswechsel) erstellt, öffnet sich ein Assistent mit 3 Comboboxen und einem Eingabefeld.

Zuerst ist nur die erste Combobox, welche die Sprachen enthält, aktiv. Nach der Sprachwahl wird die 2. Combobox mit allen Verlagen in diesem Sprachgebiet (soweit bekannt/gepflegt) gefüllt und der Benutzer kann sich den Verlag aussuchen. Nach der Verlagswahl wird die 3. Combobox mit allen (bekannten) Serien dieses Verlages gefüllt und der Benutzer kann sich die richtige Serie heraussuchen. Schließlich gibt er die Heftnummer ein, der Schlüssel ist fertig und die Daten werden vom Assistenten in die richtigen Felder der Eingabemaske übertragen.

(Entschuldige den Umweg über einen Assistenten aber die Eingabe über die bisherige Eingabemaske würde eine Eingabe in der Reihenfolge Serie, Verlag, Sprache verursachen und das dürfte zu einen hohen Anteil an Fehlerkennungen bzw Nichterkennungen führen weil z.B. der Verlag "Marvel" statt dem Verlagslabel "Marvel Deutschland" des Pannini-Verlages im deutschen Sprachgebiet gewählt wurde.)

Es gibt nur das Problem, was passiert, wenn der Benutzer seine gewünschte Serie (oder den Verlag) nicht findet?

Dies kann eigentlich nur 2 Ursachen haben:

1. Er hat eine Lücke (neue, exotische bzw. nicht angelegte {ur-}alt Serie) entdeckt. In diesem Fall muß ein freundlicher CK-Zentraldatenbank-Redakteur die fehlenden Daten nachpflegen.

2. Er hat sich im Gewirr der Verlage, Verlagsumbenennungen, Verlagslabel verirrt und deshalb die Serie nicht gefunden. Hier muß ebenfalls ein hoffentlich nach dem 20. DAU immer noch freundlicher CK-Zentraldatenbank-Redakteur dem User auf den richtigen Weg leiten.

Die Frage lautet nun, was passiert in der Wartezeit (in Urlaubszeiten ca 3-5 Wochen) auf Userseite?

IMHO darf kein Schlüssel erstellt werden, damit ein Nachpflege-Assistent sämtliche Hefte mit fehlendem Schlüssel finden und zur (manuellen) Nachbereitung mit gleichzeitiger Korrektur der Namen auf die festgelegten Standardnamen für Verlag und Serie anbieten kann.
Man könnte zwar eventuell mit einem eindeutig unbekannten Hilfsschlüssel (Verlag=999 und fortlaufende Serie) arbeiten um die Korrektur bei größeren bisher unbekannten/nicht identifizierten Serien zusammen zu fassen und damit zu erleichtern, aber es bleibt IMHO die manuelle Zuordnung durch den User als einzige Möglichkeit um temporäre Fehlentscheidungen des Redakteurs (die Serie "Kamikaze" aus dem Pannini-Verlag {richtig wäre Label "Planet Manga"} kenne ich nicht - das muß "Kamikaze Kaito Jeanne" bei EM&A sein) auszusitzen.

cuagn Thomas

PS: Das Ganze bedeutet jedoch, daß im CK eine "Grunddatenbank" mit allen 1000-2000 Serien vorhanden sein muß (sehe ich kein Problem - Tabelle in der Datenbank oder Liste macht Platzmäßig keinen Unterschied und erstere ist leichter aktualisierbar).
Dazu kämen jedoch noch ca 200 Verlage und Verlagslabel - und hier stellt sich mir die Frage, ob diese wirklich mit allen Daten in der Grunddatenbank verankert werden sollten oder "nur" mit ihrem Namen und Schlüssel. Schließlich dürfte ein großer Teil (independent Selbstverlage, erloschene Heftverlage aus den 50ern - vor allem in USA oder gar Japan) für die breite Masse uninteressant sein.

[tgmm]

Original geschrieben von oliver4you

Im Moment ist es ja so, dass man ein Comic sowohl als einzelnes Heft (das blaue Buch-Icon) als auch als Heft mit Story verwalten kann. Das hat schon oftmals zu Verwirrung bei den Anwendern geführt.

Was haltet ihr davon, wenn künftig jedes Heft immer mindestens eine Story in der Tabelle enthalten MUSS. Die Daten wären dann ebenfalls logisch getrennt. So würden Informationen wie beispielsweise "Einbandart", "Format", "Preis", "Zustand" dem Heft zugeordnet werden, während die Story dann Infos zu "Autor", "Darsteller", "Geschichte" usw. enthält.

Ich habe lange nachgedacht. - Schließlich war ich vor einigen Jahren, als ich mich noch am SFHINX-Projekt beteiligte, ein eifriger Verfechter der reinen Lehre von der strikten Trennung von "Werk" und "Medium".

Was jedoch für Bücher ganz sinnvoll ist (zwecks Identifikation/Unterscheidung von Lizenzausgaben und Ausgaben mit anderem Übersetzer etc.), erscheint mir im Comic-Bereich unnötig und übermäßig aufwendig - zumal ja keiner auf die Idee kommen würde, Stories und Hefte getrennt einzugeben und dann einander (via Linktabelle) zuzuordnen (also ein und derselbe Story-Datensatz wird zwei verschiedenen Heften {z.B. Normal-Ausgabe und Messe-Sonderausgabe} zugeordnet), was obiger reinen Lehre entsprechen würde.

Inzwischen bin ich etwas pragmatischer und wäge Vorteile und Nachteile ab.

Der Vorteil der Muß-Story liegt in einer Aufteilung der Tabelle für Heft/Story und einer daher weniger redundanten Datenbank.
Daten die von der Logik zusammengehören werden zusammengefasst. Die Eingabemasken werden aufgeräumter und kleiner. Die Suchfunktion wird präziser wenn Hefte über Story-Eigenschaften gesucht werden (aber schwieriger einzugeben).
Da alle Hefte mindestens 1 Story haben werden Story-Einträge, insbes. einzelne Story-Einträge (die geschaffen wurden um neben dem Hefttitel auch den Storytitel der einzigen Story des Heftes unterzubringen) oder Story-Einträge von Spezial-Ausgaben die ausnahmsweise als Storyband mit Kurzgeschichten anstelle der normalen Heftlangen-Story herausgegeben wurden, nicht mehr übersehen.

Nachteilig ist jedoch, daß es z.B. bei den Eigenschaften "Heft-Eigenschaften" (Auflage, Sonderausgabe, Signaturen, Seitenzahl) und "Story-Eigenschaften" (Farbe, Typ {Manga, Franko-Belgisch}, Seitenzahl) gibt. Einige Felder müssen somit trotzdem doppelt verwaltet werden.
Weiterhin ist vermutlich bei der Muß-Story nicht direkt ersichtlich ob es sich um einen (minimalst mit Genre, Sprache, Autor) ausgefüllten Muß-Eintrag handelt, das Heft aber mehrere Stories aufweist oder ob das Heft wirklich nur eine Story beinhaltet.
Suchen werden schwieriger einzugeben (aber präziser).

Zusammenfassend würde ich sagen, daß sich der Aufwand (sofern er nicht aus anderen Gründen notwendig wird) nicht lohnt.

Wenn aber die Änderung durch andere Anforderungen/Änderungen notwendig wird, sollten obige Warnpunkte (Doppelte Führung von Eigenschaften bzw Seitenzahl und Kennzeichnung von minimalistischen Muß-Story-Einträgen) beachtet werden um die Vorteile realistisch nutzen zu können

cuagn Thomas

PS: Leider würde sich die Änderung beim Mißbrauch des ComicKeepers für andere Sammlungen (Briefmarken, Münzen, Überraschungseier, Schmuck) vermutlich eher als störend bemerkbar machen oder (wie schon oben erwähnt) bei Büchern nicht weit genug gehen.
Ja ich weiß, CK steht für Comic-Keeper und nicht für Collection-Keeper aber er eignet sich (momentan) so schön für fast jede Art von Sammlung :)

[Der_Archivar]

Die DC Datenbank wird so aufgebaut sein, daß zu jeden Heft ein Story-Eintrag zu finden ist.

Der Grund ist der, daß ansonsten einige Angaben unter den Tisch fallen würden.

Beispiele u.a.:

Cover-Darsteller
Cover-Autoren
Seitenzahl der Geschichte
Datum vom Cover bzw. Impressum

Natürlich gibt es einige Felder, die doppelt vorhanden sind.
Format und Verlag fallen mir spontan ein. Die beiden Angaben beziehen sich jedoch definitiv auf das Heft und bleiben somit beim Story-Eintrag leer.

Wen es interessiert, wie die Eingaben bei uns aussehen: Mail an DC-Archiv@gmx.net mit dem Hinweis "Her mit der Eingabe-Anleitung", und ich schick sie Euch zu.

Gruß Archi

[Der_Archivar]

Original geschrieben von Rince


Hi,

theoretisch sehe ich das auch so. Aus leidvollen beruflichen Erfahrungen, ich betreue Server/User in einem größeren Netzwerk, kann ich Dir sagen, das man leider bei vielen Leuten nicht viel vorraussetzen darf. (Nicht negativ gemeint, aber leider setzen sich nicht allzuviele Leute mit ihren Arbeitsgeräten auseinander. Ebenso sitzt der Fehler in vielen Fällen vor dem Monitor.)
Um also viele Probleme von Anfang an ausschließen zu können, spricht vieles für eine automatische Vergabe.

mfG
Lars

Oh ja, das Problem kenne ich von meiner Arbeit her.

Gottseidank sind die Jungs, die die DC Datenbank eingeben, etwas sorgfältiger.

Denn was bringt mir die Datenbank, wenn die Einträge nicht stimmen. Da kann ich das ganze Ding in die Tonne treten.

Das wird übrigens mein Wahlspruch für das neue Jahr: "Ebenso sitzt der Fehler in vielen Fällen vor dem Monitor".

Danke, Rince !!!

[Rince]

Original geschrieben von tgmm

Wir reden anscheinend wirklich aneinander vorbei, da Du unbedingt die 3 verschiedenen Ansätze miteinander vermengen willst. Da du am Konzept der Packages nicht interessiert bist (die brauchen nähmlich keinen Schlüssel, da die Auswahl von einem stinknormalen Webserver {z.B. über ein Cover-Thumbnail} erfolgt) vergessen wir erst mal Deine Äußerungen zu den Packages und gehen zu der Key-gesteuerten, automatischen Distribution via Webservice bzw. Aktive-X o.ä. über.


Hi,

das ich kein Interesse an Packages habe ich nicht gesagt.
Ich kann mir im Moment nichts genaues darunter vorstellen. Ist ein Package ein exportiertes Comic?
Hat es ein andere Format?
Warum sollten nicht beide Formate nebeneinander bestehen?



Erst einmal 2 Fragen:

1. Woher nimmst du Standardwerte für einen Hefttitel?
Wir haben es ja noch nicht einmal geschafft, uns auf einen Standard für so einfache Dinge wie Genre und Heftformat zu einigen. (Wenn der letzte Benutzer begriffen hat, daß er z.B. statt "XMen (neu)" nur "X-Men neu" schreiben darf, dann brauchen eigentlich keine Schlüssel mehr :) )


Da es nicht immer einen Heftitel gibt, denke ich er wird nicht für den Schlüssel benötigt. Ich denke für den Schlüssel reichen Serie, Verlag, Heftnummer, Land, Variant. Diese Werte müssen natürlich eindeutig sein. Anders hat es keinen Sinn.
=> Diese Werte müssen einheitlich sein.



2. Was soll der lokale Schlüssel?
Ich vermute Du willst Ihn verwenden um die Serien zu verwalten, zu denen es bisher keinen zentralen Serienschlüssel gibt. Aber dies wäre IMHO zu spät und tödlich, da erst einmal die große Diskussion ausbrechen würde ob nun die Serien "XMen (superneu)" und "X-Men super" identisch seien, bis der neue Zentral-Serienschlüssel definiert ist und dann (händisch) aus dem lokalen Schlüssel der Einheitsschlüssel gemacht werden müßte.


Nö, der lokale Schlüssel ist im lokalen System eindeutig. Erst beim Upload auf den zentralen Server wird ein weiterer Teil des Schlüssels erzeugt und an den lokalen Schlüssel angehängt. Durch den lokalen Teil des Schlüssels ist das Comic "eindeutig" identifizierbar, denn alle "gleichen" COmics sind bis auf die Serverkomponente des Schlüssels gleich. Die Comics sind, so denke ich anhand ihres Schlüssels einsortiert. duch die Position des Heftes in der DB gibt es einen Indexwert. Also, wenn schon 10 Personen das Comic geuppt haben, ist beim 11 Comic der Serverseitige SChlüsselanteil 10 oder 11, je nachdem wo der Index beginnt (0 oder 1). DIeser Schlüssel wird beim uppen dem Comic auf dem Server zugeordnet und auch in die lokale DB übertragen. Der Schlüsselteil könnte also lokal, ohne Übertragung immer Null sein. Die Anzahl der Stellen für diesen Schlüsselteil vernachlässigen wir erstmal. Damit dürfte eine Einheitlichkeit gegeben sein.
Nachteil: selbst verzapfte Titel(Seriennamen) sind natürlich Problematisch. Abhilfe dazu später.




Man könnte natürlich (frei nach dem Film "Die Lady und ihre Gauner") auch eine automatische Korrekturliste verteilen mit der alle ungewollten Schreibweisen in die "Einheitsschreibweise" umgewandelt würden. Sollte aber später eine ungewollte Schreibweise für eine neue Serie zur Einheitsschreibweise werden hätten wir ein Problem.

Jupp, so stelle ich es mir vor. Bei jedem Connect(?) werden die Standardwerte abgeglichen. Zu Deinem Problem OK, ist einsehbar, aber wenn ich hier nach der Methode der wandernden User-Profile bei Windows NT gehe, dann hat der Server immer Recht. Das heißt seine schreibweise gewinnt. Um einen vernünftigen Abgleich der verschiedenen Schreibweisen zu sichern ist ggf. ein Assistent, oder/und mitgeführte Listen notwendig, die helfen die verschiedenen aufgelaufenen Schreibweisen auf die aktuelle zu bringen.




Vom Vollständigkeit-Schlüssel halte ich verhältnismäßig wenig, da er eigentlich nur treffen würde wenn der Datenaustausch automatisch bidirektional (also auch Daten werden automatisch in die Zentraldatenbank importier) verlaufen würde. Ein solcher Automatismus (ohne redaktioneller Einflußnahme) würde aber entweder den schnellsten Benutzer (egal ob Daten richtig oder nicht) präferieren oder innerhalb kürzester Zeit die Zentraldatenbank korrumpieren.
Außerdem müßte solch ein Schlüssel genau beschreiben welche Informationen vorrätig sind und welche nicht (eine Prozentangabe ist niedlich aber sinnlos).


Den sehe ich halt als Option. Je nachdem, wie komplett man ein Comic haben will, sucht man sich das entsprechende raus. Der Prozentwert kann nicht alles abbilden, OK, ebenfalls möglich wäre ein Bitschlüssel, der genauso lang ist, wie die Anzahl der felder eines Comics. 0 = Kein Wert , 1 = Daten vorhanden. Wie man das dem User visuell darstellt ist eine andere Geschichte. Nimmt man den Integerwert als Kurzreferenz? Mit einer Legende könnte man dann den Integerwert umsetzen. Aber das ist ein anderes Thema.
Sieh die die Seite www.coverscans.de mal an, da existieren ebenfalls einige Cover mehrfach. Ich weiß jetzt nicht, ob dort die Auflösung mit angegeben ist? Dieses wäre ja eigentlich auch eine Angabe über die Qualität des Covers.



Ich sehe das im Prinzip ähnlich - nur ist das nicht das, was wir momentan mit der CD machen.

...

Eine solche Investition ist für viele unerschwinglich (Laut einem Gespräch mit Oliver sucht tooligan noch einen Sponsor der bereit ist, die notwendige Infrastruktur für mehrere Jahre zur Verfügung zu stellen)

Die große Gefahr besteht außerdem darin: Wer zahlt, der bestimmt.
Und dies kann dann dazu führen, daß auf einmal bestimmte Serien, Verlage oder im Handel vergriffene Hefte etc nicht mehr über die CK-Zentraldatenbank verwaltet werden können.

Schließlich und endlich steht und fällt dann jeder Datenaustausch mit der Betriebsbereitsschaft der Zentraldatenbank - für mich eine grausige Vorstellung.

OK ist eine Gefahr. sehe ich ein. Ich habe Deine Idee ja nicht abgelehnt. Ich habe nur meine dagelegt. Was spricht gegen eine Kombination? Was spricht gegen mehrere DBs (www.cddb.com/www.freedb.com(?))



Ich habe vCards vorgeschlagen als bekanntes Standardformat für den Austausch von Kontaktadressen. Genau so gut könnte es auch eine XML-Datei oder etwas ganz anderes sein.
....
cuagn Thomas

Wie ich schon schrieb, habe keine Ahnung von den VCards. Wie das Format für den Austausch sein soll, ist doch egal, Hauptsache es ist kompakt, leicht handlebar und bietet Möglichkeiten gegen Datenmanipulationen/kurruptionen.
Das eine Vielzahl von Austauschmöglichkeiten gut ist ist logisch. Das diese Möglichkeiten nicht unbedingt die gleichen Techniken nutzen sollten....
Außerdem sollte man auch bedenken, das nicht jeder unbedingt einen Internetzugang hat. Du siehst ich habe nichts gegen Deine Idee, ich habe nur einen anderen Ansatz.
Ich hoffe Du hast mich jetzt wieder lieb. :engel:

mfG
Lars

[Rince]

Original geschrieben von tgmm


Ich habe mir gerde einen neuen Druckertreiber geladen und dabei ist mir (hoffentlich) der Groschen gefallen, wie Du dir die "halbautomatische" Schlüsselermittlung vorstellst. (Bitte korrigiere mich)

Wenn der Benutzer einen "Serienordner" (nur eine Serie im Ordner) oder ein Heft in einem "Sammelordner" (mehrere Serien in einem Ordner bzw. Verlagswechsel) erstellt, öffnet sich ein Assistent mit 3 Comboboxen und einem Eingabefeld.

.........

(Entschuldige den Umweg über einen Assistenten aber die Eingabe über die bisherige Eingabemaske würde eine Eingabe in der Reihenfolge Serie, Verlag, Sprache verursachen und das dürfte zu einen hohen Anteil an Fehlerkennungen bzw Nichterkennungen führen weil z.B. der Verlag "Marvel" statt dem Verlagslabel "Marvel Deutschland" des Pannini-Verlages im deutschen Sprachgebiet gewählt wurde.)


Jupp, so in der Art habe ich es mir Vorgestellt.
Anders ist es eigentlich nicht möglich. Den Assistenken könnte man viellelicht wie folgt optimieren. Da das Comic immer unterhalb einer Serie steht, übernimmt der Assistent die Werte aus dem Sammlungsordner. So muß man dann ggf. für den Schlüssel nur noch die Heftnummer angeben. Aber das ist jetzt nur so eine Idee, da gibt es bestimmt noch andere gute Ideen.



Es gibt nur das Problem, was passiert, wenn der Benutzer seine gewünschte Serie (oder den Verlag) nicht findet?

Dies kann eigentlich nur 2 Ursachen haben:

1. Er hat eine Lücke (neue, exotische bzw. nicht angelegte {ur-}alt Serie) entdeckt. In diesem Fall muß ein freundlicher CK-Zentraldatenbank-Redakteur die fehlenden Daten nachpflegen.

2. Er hat sich im Gewirr der Verlage, Verlagsumbenennungen, Verlagslabel verirrt und deshalb die Serie nicht gefunden. Hier muß ebenfalls ein hoffentlich nach dem 20. DAU immer noch freundlicher CK-Zentraldatenbank-Redakteur dem User auf den richtigen Weg leiten.

Die Frage lautet nun, was passiert in der Wartezeit (in Urlaubszeiten ca 3-5 Wochen) auf Userseite?



Das ist das Problem mit den Standardwerten. Es muß eine Instanz geben, die die Werte festlegt. Was ist diese Instanz? IMHO kann es nur ein Mensch sein. Bei neuen Serien ist, so denke ich, die Schreibweise des Verlages. Wenn die bei der Geschichte mitspielen, so könnten sie diese Daten der Db bereitstellen, oder man nimmt dafür die GA. Nun muß noch ein "doofer" das ganze freischalten.



IMHO darf kein Schlüssel erstellt werden, damit ein Nachpflege-Assistent sämtliche Hefte mit fehlendem Schlüssel finden und zur (manuellen) Nachbereitung mit gleichzeitiger Korrektur der Namen auf die festgelegten .......

So, muß mir das Kürzen langsam angewöhnen.
Dieses ist das Hauptprob, da gebe ich Dir Recht. Siehe dazu mein anderes Posting. Hier muß man sich etwas narrensicheres überlegen. Aber das würde hier den Rahmen sprengen.



PS: Das Ganze bedeutet jedoch, daß im CK eine "Grunddatenbank" mit allen 1000-2000 Serien vorhanden sein muß (sehe ich kein Problem - Tabelle in der Datenbank oder Liste macht Platzmäßig keinen Unterschied und erstere ist leichter aktualisierbar).
Dazu kämen jedoch noch ca 200 Verlage und Verlagslabel - und hier stellt sich mir die Frage, ob diese wirklich mit allen Daten in der Grunddatenbank verankert werden sollten oder "nur" mit ihrem Namen und Schlüssel. Schließlich dürfte ein großer Teil (independent Selbstverlage, erloschene Heftverlage aus den 50ern - vor allem in USA oder gar Japan) für die breite Masse uninteressant sein.

Jupp, hier habe ich kein Prob, so habe ich es mir vorgestellt. Ich denke die Menge der Daten ist von deren Größe abhängig. Gehen wir davon aus, alle Daten mitgeliefert werden, damit wäre eine auf jeden Fall eine Einheitlichkeit gegeben. Die Nachpflegezeiten wären minimiert. Wie wäre da ein optionaler Assisten, der hilft die für den Sammler relevanten Daten zu aktivieren?
Man könnte es sich so vorstellen, die Daten sind vorhanden, aber deaktiviert, wie die Kategorien. Mit aktivioeren der Daten, werden sie sichtbar. Mein Vorschlag war vor langer Zeit so etwas wie eine Baumstruktur.

Als Bsp:
Ich interessiere mich für Marvel, aber nicht für DC. gehen wir davon aus das alle benötigten Daten in der DB vorhanden sind. Aktiviere ich nun Marvel, so bekomme ich von den vorhandenen Daten nur noch Marvel zu Gesicht. Wähle ich nun in einigen Bereichen "Die Spinne " aus, so wird mir weiter unten auch nur etwas von der Spinne angeboten. Der ganze Rest fällt weg. Wenn das mit allen Daten so passiert, sollte die Fülle der Daten, die für einige uninteressant sind, ohne interesse sein, da der User nur die für benötigten sehen.

Marvel
Williams
Die Spinne

=> Condor, Hit Comics usw sehe ich nicht.

So, ich hoffe ich langweile Euch nicht allzusehr.

mfG
Lars

[Rince]

Original geschrieben von Der_Archivar


Oh ja, das Problem kenne ich von meiner Arbeit her.

Gottseidank sind die Jungs, die die DC Datenbank eingeben, etwas sorgfältiger.

Denn was bringt mir die Datenbank, wenn die Einträge nicht stimmen. Da kann ich das ganze Ding in die Tonne treten.

Das wird übrigens mein Wahlspruch für das neue Jahr: "Ebenso sitzt der Fehler in vielen Fällen vor dem Monitor".

Danke, Rince !!!

Ich sage immer:

Der Fehler sitzt immer vor dem Monitor.

;) Es läßt sich auch noch sagen:
Wer lesen kann ist klar im Vorteil. :p
Denn wer sich alles mal genauer durchliest, kann Fehler vermeiden und erkennen. Ich schließe mich davon nicht aus. Man ist hat oft sehr oberflächlich.

Ich finde es aber gut, wenn ich Dir etwas mitgeben konnte.

mfG
Lars

[beni]

zum thema "wie wäre diese ideale software genau?":

es gäb sie auch in einer mac-version!

[oliver4you]

Was haltet Ihr von dem Szenario:

Es gibt nur eine zentrale Datenbank in die nicht jeder ComicKeeper-Anwender uploaden kann. Verwaltet wird die Datenbank von Administratoren, die für eine oder mehrere Serien zuständig sind. Sie sind letztendlich für die Daten verantwortlich und können diese dann auch freigeben . Bei der riesigen Menge an Serien kann jeder Sammler relativ einfach Administrator werden. Er meldet sich für eine Serie als Admin an – es wird überprüft ob es die Serie schon gibt – und wenn nicht, dann erhält er das Recht für diese Serie und ist ab dann dafür zuständig.

Es gibt festgelegt Regeln, an die sich jeder Admin bei der Eingabe halten muss.

Auch mehrere Admins können an einer Serie arbeiten.

Es gibt nur Standardwerte ( Sprache, Genre, Einbandart, Format ) in den Datenarchiven der zentralen Datenbank. Wenn sich ein Sammler Comics aus der Datenbank downloadet, dann sind die Standardwerte nicht veränderbar. Sollte ein Wert in der zentralen Datenbank fehlen, dann wird er (nach Absprache mit den anderen Admins) eingepflegt.

Der Sammler kann weiterhin seine eigenen Datenarchive-Einträge pflegen, für den Fall, dass er nicht nur Comics mit dem Keeper verwaltet. Diese Angaben können aber nicht einem Comic aus der zentralen DB zugewiesen werden.

Der Anwender durchsucht mit dem Keeper als Online-Browser die zentrale Datenbank im Internet und kann genau angeben, welche Comics er in seine lokale Datenbank herunterladen möchte.

[oliver4you]

@tgmm
Zum Thema "In jedem heft muss mindestens eine Story vorhanden sein"

In einer der nächsten Versionen kann der Anwender genau festlegen, welche Eigenschaften er für ein Comic verwalten möchte.

Was hältst Du von der Lösung, dass man auf Ordnerebene angeben kann, welche Eigenschaften für die darin enthaltenen Hefte/Stories angezeigt werden sollen. Somit muss es keine mehrfach vorhandenen Eigenschaften geben.