Ideen für CK Updates

[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.
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.