Ideen für CK Updates (Austausch DBs)
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
mfG
Rince
P.S. Ich hoffe ich habe nicht zuviel geschrieben.
Geändert von Rince (24.11.2002 um 20:21 Uhr)
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
Die Idee finde ich gar nicht so schlecht. Ist natürlich eine Frage, ob dies machbar ist. Ich vote aber jedenfalls dafür
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.
Habe noch nen Satz eingefügt. Hoffe der Trifft Deine Zustimmung.
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
Olli hat mich bei meinen abgedrehetn Ideen eh nicht lieb.....
mfG
Rince
...Olli hat mich bei meinen abgedrehetn Ideen eh nicht lieb.....
Hi Lars - stimmt gar nicht
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
Grüßle
Oli
Hi,Original geschrieben von oliver4you
...Olli hat mich bei meinen abgedrehetn Ideen eh nicht lieb.....
Hi Lars - stimmt gar nicht
da bin ich aber beruhigt. Hatte schon Panik
Super Super
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.
Dazu kann ich nur dieses sagen:
Oh Anbetungswürdiger
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.
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.
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.
- Auch mit dem Datenschutz ist es so eine Sache. Wer möchte schon, dass ein Fremder Dateien auf der Festplatte durchwühlt.
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
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.
- 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.
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
@Rince: Danke ! Ich hatte schon befürchtet, mich zu oberlehrerhaft anzuhören.
Was soll denn das heissen ? Die Software gibt´s doch schon ?!?
Wie sollte die perfekte Software zum verwalten von Comics aussehen und was soll alles möglich sein? [/B]
Welche Software kann schon von sich behaupten, 100% perfekt zu seinOriginal geschrieben von Der_Archivar
Was soll denn das heissen ? Die Software gibt´s doch schon ?!?
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.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
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
zu Thomas
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.
Geändert von Rince (29.11.2002 um 22:00 Uhr)
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?
Finde die Idee mit dem Kürzel super.
SSS wird für die Angabe der Serie stehen.
Gruß Archi
Hi,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?
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
Genau, um halb Sechs in der Früh darf einem doch mal so ein Flüchtigkeitsfehler passieren.Original geschrieben von Der_Archivar
Finde die Idee mit dem Kürzel super.
SSS wird für die Angabe der Serie stehen.
Gruß Archi
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
Sorry, aber Du hast mich anscheinend nicht ganz verstanden.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ß.
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
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 generierenOriginal 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.
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.
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
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).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.
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
Geändert von tgmm (01.12.2002 um 12:23 Uhr)
Hm, stimmt; das macht Sinn!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.
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.
Hi,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?
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.
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.
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 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.
Ok ist einsehbar. Aber warum VCards? Wenn ich mich recht erinnere gab es bei denen doch eine Sicherheitslücke. Oder ist sie schon gefixed?
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.
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.
Wie Du an meinen Ideen sehen konntest denken wir beides an das gleiche
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
mfG
Lars
Geändert von Rince (03.12.2002 um 20:24 Uhr)
Jupp einer versteht mich B^) Aber leider nur Teilweise.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.
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.
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)
@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.
mfG
Lars
Hi,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
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
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.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.
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).
Ich sehe das im Prinzip ähnlich - nur ist das nicht das, was wir momentan mit der CD machen.
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.
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.
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.
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 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
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)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.
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.
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".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.
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
Berechtigungen
|
Das Splash-Netzwerk: Splashp@ges
- Splashbooks
- Splashcomics
- Splashgames
Unsere Kooperationspartner: Sammlerecke - Chinabooks - Salleck Publications - Splitter - Cross Cult - Paninicomics - Die Neunte Comicsalon Erlangen Lustige Taschenbücher |
Zitieren
Lesezeichen