Hersteller-/ISBN-Code-Feld

Hier kommen ausschließlich Hinweise auf Korrekturen und Ergänzungen von bestehenden OGDB-Einträgen rein. Aussagekräftige Themen-Bezeichnungen und Links auf entsprechende Einträge in den Themen selber sind ausdrücklich erwünscht.

Moderator: OGDB Tech

Antworten
Nachricht
Autor
Benutzeravatar
Bodonator
Beiträge: 197
Registriert: Dienstag, 18. Mai 2010, 15:11

Hersteller-/ISBN-Code-Feld

#1 Beitrag von Bodonator » Donnerstag, 5. November 2015, 05:09

Hab mal n neuen Thread aufgemacht, damit das Thema nicht im Klärung und Absprache von Verbesserungsvorschlägen-Thread untergeht.
Also:

Da das Thema in den letzten Tagen wieder aktuell wurde, die Anzahl betroffener Versionen eher steigt,
als zu fallen und da bei dieser Angelegenheit berechtigterweise immernoch zu viel Unklarheit herrscht, folgende Anmerkungen:

In das Hersteller-/ISBN-Code-Feld gehören definitiv ALLE in/auf der jeweiligen Version findbaren
Codes/Artikelnummern/ISBN/Revisionsnummern/Hersteller-Codes/usw..
Natürlich auch die, die auf Gebrauchs-/Epilepsiehinweisheftchen, Faltblättern, Flyern, Inlays, Werbebroschüren, Poster,
Laschen, Gewinnspiel-Postkarten, Club Nintendo-Antwortkarten (u. sonstige Registrierkarten) stehen.
Wenn nicht sogar vor allem diese.

Die Information, wo der jeweilige Code (auf Verpackung o. Modul..) zu finden ist, gehört allerdings NICHT in dieses Feld.
Falls Codes mehrfach vorhanden sind, wird dies ebenfalls NICHT in diesem Code-Feld deutlich gemacht.
Beides sollte bitte im Informationstext weiter unten untergebracht werden.

Also nicht:

Hersteller-/ISBN-Code: AA32X37 (Box), 571/VX7 (Modul), 6482137 / 571/VX7 (Booklet), 4V<# / 9205T (Infoheftchen)

Sondern:

Hersteller-/ISBN-Code: AA32X37, 571/VX7, 6482137, 4V<#, 9205T


Im Infotext könnte dann z.B. so etwas stehen wie:

• Codierungen:

- AA32X37 (Box)
- 571/VX7 (Modul)
- 6482137, 571/VX7 (Booklet)
- 4V<#, 9205T (Infoheftchen)


Alternativ kann man es z.B. auch in der Inhaltsangabe mit unterbringen:

• Lieferumfang:

- Standard-Miwembo69-Papphülle (Covertexte auf Deutsch, Codierung: AA32X37)
- Kartonhalterung für das Modul
- PAL-Miwembo69-Modul (Codierung: 571/VX7)
- Plastiktütchen zum Schutz des Moduls
- Bedienungsanleitung (in Deutsch, 23-seitig, s/w, Codierungen: 6482137 & 571/VX7)
- Gebrauchs-/Epilepsiehinweisheftchen (in Deutsch & Englisch, 7-seitig, Codierung: 4V<# & 9205T)


Es gibt nämlich Codes, die Letternfolgen wie z.B. MODUL, DISC, BOX oder ART innehaben (klick).
Wenn jemand nach solch einem Code sucht, bekommt er evtl. eine Vielzahl an Vorschlägen, die nicht seinen Suchkriterien entsprechen.
Zur Veranschaulichung klicken: Art, Modul & Box

Der Einheitlichkeit halber könnte man sich darauf einigen, mit Kommata zu trennen.


Falls dieser Beitrag doch in den Klärung und Absprache von Verbesserungsvorschlägen-Thread gehört, bitte verschieben.
"If you want a vision of the future, imagine a boot stamping on a human face - forever."
-George Orwell-

"Die meisten von ihnen ahnten wahrscheinlich nicht, was sie damit anrichteten, aber die Diener des Ungeheuers wußten sehr wohl, was sie taten.
Und sie leisteten ganze Arbeit.
"

-Jean Raspail-

Benutzeravatar
LiquidSnakE
OGDB Support
Beiträge: 3904
Registriert: Freitag, 14. Dezember 2007, 13:45
Wohnort: AT/EUSSR

Re: Hersteller-/ISBN-Code-Feld

#2 Beitrag von LiquidSnakE » Donnerstag, 5. November 2015, 10:33

Als jemand, der des von dir angekreideten Verhaltens "schuldig" ist, habe ich ein paar Anmerkungen zu deinem Vorschlag:
Bodonator hat geschrieben:[...]
In das Hersteller-/ISBN-Code-Feld gehören definitiv ALLE in/auf der jeweiligen Version findbaren
Codes/Artikelnummern/ISBN/Revisionsnummern/Hersteller-Codes/usw..
Natürlich auch die, die auf Gebrauchs-/Epilepsiehinweisheftchen, Faltblättern, Flyern, Inlays, Werbebroschüren, Poster,
Laschen, Gewinnspiel-Postkarten, Club Nintendo-Antwortkarten (u. sonstige Registrierkarten) stehen.
Wenn nicht sogar vor allem diese.
Kann man machen, muss man aber nicht. Für "Normalsterbliche" ist es ein klarer Informations-Overkill, wenn im ISBN-Feld - etwa bei einer Collector's Edition, der viel Zeug beiliegt - gefühlte 100 Codes gelistet werden. Ich für meinen Teil liste ausschließlich relevante Codes (Code des Spiels bzw. Mediums, der Verpackung, kurz: äußerlich "sichtbare" Codes, die zur Identifizierung wichtig sind; kein Schwein interessiert der Code eines Nintendo-Gesundheitsflyers), hindere aber auch niemanden daran, mehr ins Detail zu gehen.
Bodonator hat geschrieben: Die Information, wo der jeweilige Code (auf Verpackung o. Modul..) zu finden ist, gehört allerdings NICHT in dieses Feld.
Falls Codes mehrfach vorhanden sind, wird dies ebenfalls NICHT in diesem Code-Feld deutlich gemacht.
Beides sollte bitte im Informationstext weiter unten untergebracht werden.

Also nicht:

Hersteller-/ISBN-Code: AA32X37 (Box), 571/VX7 (Modul), 6482137 / 571/VX7 (Booklet), 4V<# / 9205T (Infoheftchen)

Sondern:

Hersteller-/ISBN-Code: AA32X37, 571/VX7, 6482137, 4V<#, 9205T


Im Infotext könnte dann z.B. so etwas stehen wie:

• Codierungen:

- AA32X37 (Box)
- 571/VX7 (Modul)
- 6482137, 571/VX7 (Booklet)
- 4V<#, 9205T (Infoheftchen)


Alternativ kann man es z.B. auch in der Inhaltsangabe mit unterbringen:

• Lieferumfang:

- Standard-Miwembo69-Papphülle (Covertexte auf Deutsch, Codierung: AA32X37)
- Kartonhalterung für das Modul
- PAL-Miwembo69-Modul (Codierung: 571/VX7)
- Plastiktütchen zum Schutz des Moduls
- Bedienungsanleitung (in Deutsch, 23-seitig, s/w, Codierungen: 6482137 & 571/VX7)
- Gebrauchs-/Epilepsiehinweisheftchen (in Deutsch & Englisch, 7-seitig, Codierung: 4V<# & 9205T)
Again: Kann man, muss man aber nicht. Es gibt genug User, die es exakt so handhaben, wie du es hier beschreibst. Völlig legitim, völlig okay, sollte aber nicht zur "Pflicht" gemacht werden.

Ich halte mich in dieser Frage an eine der Grundregeln im Journalismus, die sich hier ebenso anwenden lässt, nämlich das KISS-Prinzip: "keep it short and simple". Ich sag's erneut: Kein "Normalsterblicher" kann mit diesen Angaben etwas anfangen oder interessiert sich dafür. Keiner. Ich wage sogar, zu behaupten, dass sich niemand außer die größten Hardcore-Vintage-Sammler dafür interessieren. Wenn sich jemand die Mühe macht, sämtliche Codes abzutippen und akribisch zu dokumentieren, ist das gut und schön - aber niemals würde ich diese Handhabung zur Regel machen.
Bodonator hat geschrieben: Es gibt nämlich Codes, die Letternfolgen wie z.B. MODUL, DISC, BOX oder ART innehaben (klick).
Wenn jemand nach solch einem Code sucht, bekommt er evtl. eine Vielzahl an Vorschlägen, die nicht seinen Suchkriterien entsprechen.
Ohne die Nummern findest du die zugehörige Version niemals - was aber eigentlich keine Überraschung ist. Wer sucht schon ausschließlich nach den Worten "MODUL", "ART" etc., ohne zumindest einen Teil der ISBN zu kennen? Mir leuchtet deine Logik nicht ganz ein. Das ist, als ginge ich auf den Online-Shop von, sagen wir, Humanic und würde in das Suchfeld "Schuhe" eingeben - ist doch völlig klar, dass ich etwas spezifischer sein muss: Laufschuhe? Stiefel? Sandalen? Was suche ich? Mit der OGDB verhält es sich nicht anders. Sobald du den Code kennst, findest du auch, was du suchst.

Beispiel: "81578" oder "81578 box" oder "81578 pappbox" oder "81578-BX" finden alle Corpse Party: Blood Drive (Everafter Edition) - überhaupt kein Problem, solange du wenigstens einen Teil der ISBN kennst. ;)

Das Gegenteil dieser Eindeutigkeit wäre gegeben, würden wir wirklich alle Codes - auch die von Flyern etc. - im ISBN-Feld dokumentieren. Bleiben wir bei Nintendo als Paradebeispiel: jedem SNES-, N64-, NGC- und Wii-Spiel (bei der Wii U fehlen mir die Erfahrungswerte) lag seinerzeit ein Faltblatt mit Gesundheitshinweisen bei. Dieses Faltblatt war genormt, d.h. je nach Region lag stets das gleiche Blatt bei. Suchst du nun nach diesem Code, findest du mehrere tausend Versionen, die dich nicht interessieren. Sinnvoll?
"Alter Falter, wie du immer wieder diverse Top Titel komplett verreißt geht doch auf keine Kuhhaut mehr."
- Kaysa

"Es gibt weltweit auch keinen Nachweis, dass Christian Pfeiffer sinnvoll ist."
- Chris Schmitz (Ubisoft)

Bild
XBL: LiquidSnakeEe | PSN: LiquidSnakeEe | Steam: daNightmare

Benutzeravatar
Hedini
Beiträge: 48
Registriert: Donnerstag, 19. Januar 2006, 16:00
Wohnort: Mönchengladbach
Kontaktdaten:

Re: Hersteller-/ISBN-Code-Feld

#3 Beitrag von Hedini » Freitag, 6. November 2015, 01:04

Grüße!

Endlich kann ich mich einklinken. :wink:

Also, ich habe mit Bodonator im Vorfeld schon ein bisschen darüber gechattet und ich sehe als "Hardcore-Vintage-Sammler" die Dinge da etwas... anders. IMO liegt das Problem nicht daran, dass es niemand macht, oder dass da der Ort des Geschehens im Feld "Produktcode" hinterlegt wird, sondern an dem Feld selbst.

Zur Erklärung:
Wer es eingibt, gibt es ein. Punkt. Die Eingabe des Felds ist freiwillig und überhaupt landen da - wenn überhaupt - meistens nur Modulcodes, Verpackungscodes oder Anleitungscodes drin. Das dürften so die wichtigsten Produktcodes für gut 90% der Besucher sein, sofern die sich überhaupt für das Feld interessieren und nicht direkt zum Barcode überspringen.

Dann stellt sich die Frage, wer es abruft und das dürften wirklich nur die Hardcore-Sammler sein.
Aber hier sehe ich ein Alleinstellungsmerkmal der OGDB, dass dies eben für diesen Personenkreis angeboten werden kann. Nicht muss, auf keinen Fall. :)
Nur wenn ich es aus der Perspektive sehe, ist das Feld im jetzigen Zustand grauenhaft:
- ich würde gerne Suchabfragen starten wie "Welche Module endeten mit -EUU?", in welchen Spielen gab es Anleitungen mit "PKMN"?
- es entspricht noch nicht mal der 1. Normalform im Datenbankdesign
- als Freitextfeld wie bei den Inhaltsangaben kann ich eintippern was ich will und wie ich es will: Mal nenn ich das Ding, was ich in den Gameboy schiebe, "Cartridge", mal "Modul", mal "komisches graues Ding mit Gameboy-Schriftzug". :wink:

Ich würde gerne den Teil "Produktcode" in eine 1:n-Tabelle ausgelagert sehen mit einer Konfigurationstabelle für die Fundorte der Produktcodes ("Medium / Datenträger", "Anleitung", etc.), die dann von den Admins gepflegt wird. So viele Einträge können das nicht sein und wenn welche doppelt vorkommen, ist es auch ok.

Auf diese Weise kann nach den Informationen gezielt gesucht werden und andererseits sind wir dann nicht mehr auf unstrukturierte Textfelder angewiesen. Denn gerade die Information wo Codes gefunden werden, macht u.U. schon bei manchen Systemen ein Re-Release aus, aber wenn ich wissen will ob es einen speziellen Produktcode auf dem Modul gegeben hat, will ich mich nicht unbedingt durch alle Releases klicken müssen, um mir die Antwort "Nein" selbst zusammenzureimen.

Speziell Gamefaqs glänzt nicht immer bei den Angaben von Produktcodes und da haben wir schon qualitativ mehr zu bieten bei dem Punkt als bspw. Gamefaqs und Mobygames zusammen.

Und um noch einmal auf den Produktcode von Nintendo-Konsumentenhinweise-Blättchen zurückzukommen: Komischerweise interessiert diese Information genau mich. :mrgreen:
Bei den GC-Spielen waren diese Codes zwar ebenfalls genormt, haben aber später "explosionsartig" (ja, in Anführungsstrichen! :) ) variiert. Anfangs gab es da ein oder zwei verschiedene und später gut sechs(?) und ich sehe da kein Muster drin, was ich aber gerne würde. Speziell wenn ich diese Heftchen suche, will ich nicht immer meine komplette Sammlung durchwühlten müssen, wenn ich schnell in Erfahrung bringen könnte, dass das gleiche Heftchen wie in "Mega Man Zero Collection" (teuer und selten) in "Pokémon - Erkundungsteam Himmel" (nicht ganz so teuer und selten) vorkam.

Werbeflyer hatte ich noch nicht im Fokus, aber ich könnte mir auch vorstellen, dass es Leute gibt, die gerne den Code von Antwortkarten kennen würden, um zu sehen, ob das spiel wirklich(!) eine eigene Antwortkarte hatte.
Und nebenbei wirft das Aufschreiben und Vergleichen auch neue Fragestellungen auf: Ich bin derzeit dabei zu schauen, ob es für "Final Fantasy Legend II" für Gameboy Classic in Nordamerika von Sunsoft eine eigene Landkarte mit Sunsoft-Produktcode gab, ob dem Spiel diese fehlte im Re-Release durch Sunsoft (obwohl Teil 1 und 3 von Sunsoft eine haben) oder ob die eine mit SquareSoft-Produktcode vertrieben haben.

Letzteres kann ich mir nicht vorstellen, aber ich suche noch den Gegenbeweis.

Also ich stimme für eine 1:n-Tabelle für Produktcodes nach o.g. Schema. :respekt:


Schönen Abend noch,
Hedini
Also ich stimme für eine 1:n-Tabelle für Produktcodes nach o.g. Schema. :respekt:

Benutzeravatar
Motoko
Heilige
Beiträge: 2051
Registriert: Samstag, 15. Oktober 2005, 17:58
Wohnort: Hengasch, Landkreis Liebernich

Re: Hersteller-/ISBN-Code-Feld

#4 Beitrag von Motoko » Mittwoch, 11. November 2015, 14:35

Also ich bin ja auch ein großer Fan von Produktcodes und kann da gar nicht genug von haben. :D
Bodonator hat geschrieben:Im Infotext könnte dann z.B. so etwas stehen wie:
Im Infotext muss es dann aber stehen, wenn wir oben "(Modul)" nicht mehr verwenden dürfen, sonst wirkt das Feld "Hersteller-/ISBN-Code" auf den ersten Blick extrem kryptisch und wie LiquidSnakE schon schrieb, wird das "Normalsterbliche" eher abschrecken bzw. verwirren. Wirklich alle Codes oben im Feld und zusätzlich unten bei "Weitere Informationen/Inhaltsbeschreibung:" wirkt dann aber auch doppeltgemoppelt, oder? Hmm... Um Codes mit der Suchfunktion zu finden, muss es oben rein, logisch. Würde es erst mal helfen, wenn man bei der Suchfunktion auch das Feld "Weitere Informationen/Inhaltsbeschreibung:" mit einbezieht?

Ein Verbot von Beschreibungen wie "(Modul)" im Feld Hersteller-/ISBN-Code fände ich z.B auch dann unpraktisch, wenn bei einer Version eh nur der Code vom Modul bekannt ist. Dann hat man so eine Mini-Info doppelt oben und unten.

Hedini hat geschrieben:Ich würde gerne den Teil "Produktcode" in eine 1:n-Tabelle ausgelagert sehen
Also so ähnlich wie bei "DRM/Kopierschutz:", richtig? Das wäre natürlich eine elegante Lösung.

Hui, was bräuchten wir denn da alles neben Anleitung und Medium (mit Unterteilung Spiel und Bonus?)...
Kartonbox
Schuber
Rückseite Inlay/Box
Spine
Lasche Box (für Gameboy-Spiele z.B.)
ISBN
Garantie-Karte
Werbeflyer
Downloadcode Flyer
oder Flyer allgemein?
Sicherheitshinweise / Konsumentenhinweise
Sonstiges ^^

Ab wann sieht man diese Unterkategorien, damit es einen nicht erschlägt? Was wäre denn der "Haupt"-Produktcode? Bräuchten wir den? Bei PlayStation-Spielen ist es SLES-, BLES- etc., aber bei Nintendo? Das "AGB P BLAA" auf der Rückseite, oder doch das AGB-BLAA-NOE auf der Lasche der Box?

Aufgrund nicht vorhandener Programmierkenntnisse kann ich nicht abschätzen, wie aufwändig das ist und ob es sich dann lohnt.
Bild

Bild Bild

Benutzeravatar
Hedini
Beiträge: 48
Registriert: Donnerstag, 19. Januar 2006, 16:00
Wohnort: Mönchengladbach
Kontaktdaten:

Re: Hersteller-/ISBN-Code-Feld

#5 Beitrag von Hedini » Mittwoch, 11. November 2015, 18:06

Motoko hat geschrieben:Also ich bin ja auch ein großer Fan von Produktcodes und kann da gar nicht genug von haben. :D
Sowas will ich hören! Das ist die wahre Videospiel-Archäologie! :D
Motoko hat geschrieben:Wirklich alle Codes oben im Feld und zusätzlich unten bei "Weitere Informationen/Inhaltsbeschreibung:" wirkt dann aber auch doppeltgemoppelt, oder? Hmm... Um Codes mit der Suchfunktion zu finden, muss es oben rein, logisch. Würde es erst mal helfen, wenn man bei der Suchfunktion auch das Feld "Weitere Informationen/Inhaltsbeschreibung:" mit einbezieht?
Ich würde das Feld sukzessive ersetzen durch die Tabelle.

Von Anfang an war ich nicht dabei, aber ich kann mir vorstellen, dass das Feld mal ursprünglich für DEN EINEN Produktcode eines Spiels gedacht war, wie diese ganzen BLES-xxxxx Codes von PlayStation-Spielen oder die Modulcodes von Nintendo-Spielen. Aber irgendwann holt einen halt die Realität ein. :roll:

Bis vor ca. zwei Wochen dachte ich auch immer als verwöhnter 32-Bit-und-später-Spiele-Beobachter, dass gilt: Ein Barcode = Ein Spiel. Re-Release = neuer Barcode. ...und dann kam Nintendo. :wallbash:


Also vorstellen könnte ich mir, dass wir das jetzige Feld für den Produktcode aus dem Frontend ausblenden sollten sobald es leer ist und diese Tabelle parallel dazu einführen. Die Suchroutine müsste dann sowohl das Textfeld, als auch die Tabelle durchforsten. Wenn die Daten dann irgendwann(!) auf die neue Tabelle migriert worden sind, kann man es ganz abschalten.


Motoko hat geschrieben:
Hedini hat geschrieben:Ich würde gerne den Teil "Produktcode" in eine 1:n-Tabelle ausgelagert sehen
Also so ähnlich wie bei "DRM/Kopierschutz:", richtig? Das wäre natürlich eine elegante Lösung.
An genau sowas dachte ich. :)

Falls möglich könnte man die Anzeige wie bei den Freitexten auf Spiel / Verpackung, Modul und Anleitung beschränken. Wer mehr sehen will, klickt den Button und wird erschlagen.
Die Kategorien schauen auch super aus - wenn, sollte man damit einfach anfangen und wer was vermisst, wird sich schon melden. Infos zu Bonusspielen werden doch bei den Bonusspielen gepflegt?

Was jetzt DEN EINEN Produktcode (die Schreibweise lass ich mir eintragen :wink:) bei Nintendo-Spielen angeht, stehe ich ehrlich gesagt ein bisschen auf dem Schlauch. Rein aus dem Bauch heraus würde ich entweder sagen: Das, was in der Mitte von dem ganzen Geraffel steht, also bei AGB-BLAA-NOE das "BLAA" (halte ich für nicht intuitiv) oder der Produktcode auf dem Datenträger.

Letzteres ist - so glaube ich - im Internet am ehesten das, worunter man ein bestimmtes Spiel sucht.
Motoko hat geschrieben:Aufgrund nicht vorhandener Programmierkenntnisse kann ich nicht abschätzen, wie aufwändig das ist und ob es sich dann lohnt.
Sollte eigentlich nicht länger als 4-8 Stunden dauern und "lohnen" tut sich Ordnung immer. :mrgreen:


Gruß,
Hedini
Also ich stimme für eine 1:n-Tabelle für Produktcodes nach o.g. Schema. :respekt:

Benutzeravatar
Bodonator
Beiträge: 197
Registriert: Dienstag, 18. Mai 2010, 15:11

Re: Hersteller-/ISBN-Code-Feld

#6 Beitrag von Bodonator » Montag, 30. November 2015, 23:52

Hallo!
Vielen Dank schonmal für eure Antworten.
Ich würde sehr gerne auf viel mehr einzelne Punkte eingehen, habe aber im Mom. so gut wie keine Zeit, weswegen ich auch erst so spät antworte.
Worauf ich aber kurz eingehen möchte:

1.
LiquidSnakE hat geschrieben:Again: Kann man, muss man aber nicht. Es gibt genug User, die es exakt so handhaben, wie du es hier beschreibst. Völlig legitim, völlig okay, sollte aber nicht zur "Pflicht" gemacht werden.
LiquidSnakE hat geschrieben:Ohne die Nummern findest du die zugehörige Version niemals - was aber eigentlich keine Überraschung ist. Wer sucht schon ausschließlich nach den Worten "MODUL", "ART" etc., ohne zumindest einen Teil der ISBN zu kennen? Mir leuchtet deine Logik nicht ganz ein. Das ist, als ginge ich auf den Online-Shop von, sagen wir, Humanic und würde in das Suchfeld "Schuhe" eingeben - ist doch völlig klar, dass ich etwas spezifischer sein muss: Laufschuhe? Stiefel? Sandalen? Was suche ich? Mit der OGDB verhält es sich nicht anders. Sobald du den Code kennst, findest du auch, was du suchst.
Motoko hat geschrieben:Ein Verbot von Beschreibungen wie "(Modul)" im Feld Hersteller-/ISBN-Code fände ich z.B auch dann unpraktisch, wenn bei einer Version eh nur der Code vom Modul bekannt ist. Dann hat man so eine Mini-Info doppelt oben und unten.
Achso.
Also ich bin mal so frei, KT an dieser Stelle zu zitieren;
Aus einer PN vom 31.03.13 an mich:
KT hat geschrieben:Kannst du bitte Details beim Herstellercode im normalen Text unterbringen und im Feld selber nur die Codes. Also nicht "[Modul: xxxxx], ... ", sondern einfach nur "xxxx".
Hintergrund ist, dass dieses Feld durchsucht wird, und wenn einer nach "Modul" sucht, findet er solche Einträge, obwohl das nicht Sinn der Sache ist ;)
Vor einem Monat habe ich ihn nochmal angeschrieben und gefragt, ob dies immernoch gilt:
KT hat geschrieben:Hi, ja, das gilt eigentlich immer noch (ich hab da in letzter Zeit überhaupt nicht drauf geachtet)
Ich hielt es nicht für nötig, dies bei meiner Threaderöffnung mit in den Post zu kopieren,
da ich davon ausging, das zumindest Administration & Support davon Kenntnis hat.

2.
Motoko hat geschrieben:Im Infotext muss es dann aber stehen, wenn wir oben "(Modul)" nicht mehr verwenden dürfen, sonst wirkt das Feld "Hersteller-/ISBN-Code" auf den ersten Blick extrem kryptisch und wie LiquidSnakE schon schrieb, wird das "Normalsterbliche" eher abschrecken bzw. verwirren. Wirklich alle Codes oben im Feld und zusätzlich unten bei "Weitere Informationen/Inhaltsbeschreibung:" wirkt dann aber auch doppeltgemoppelt, oder? Hmm... Um Codes mit der Suchfunktion zu finden, muss es oben rein, logisch. Würde es erst mal helfen, wenn man bei der Suchfunktion auch das Feld "Weitere Informationen/Inhaltsbeschreibung:" mit einbezieht?
Da die Ortsangabe nicht ins Code-Feld gehört und das zus. Info-Feld nicht von der Suche erfasst wird, gibt es z.Z. keine bessere Lösung als oben die Codes rein, unten dann die Ortsangabe.
Welche schon erfolgen sollte.
Da ich für mich noch nicht entschieden habe, welche Variante der Unterbringung der Ortsbeschreibung besser ist, mache ich es mal so wie hier und mal so wie dort (klick).

Ich kann mir nicht vorstellen, dass jenes Info-Feld in Zukunft suchtechnisch mit erfasst wird.
Aber die Möglichkeit, auch diese Felder in der Versionen-Suche durchleuchten zu können, ist nicht uninteressant.
Hätte ich bei meiner Arbeit schon des öfteren genutzt, wenn ich gekonnt hätte. Hmm...

Bin anscheinend wohl nicht normalsterblich.
Ein ausführlich bestücktes, sauber (z.B. mit Kommata) getrenntes Code-Feld wirkt auf mich in keiner Weise kryptisch, verwirrend, usw. oder wie ein Overkill.
Im Gegenteil. Was mich aber gelegentlich verwirrt, ist, dass Codes mal mit /, mal mit , oder mit sonst. Zeichen, manchmal sogar ohne Leerzeichen getrennt werden.
Oder wenn man in einem Eintrag schon in den Thumb-Bildern (also quasi von weitem) sieht, dass die Version mehr Codes trägt, als im Code-Feld zu lesen sind.
Wenn bei einer Special Edition so viel codierter Kram beiligt, das am Ende 20 Codes im entsprechenden Feld eingetragen sind, ist es eben so.
Kommt halt mal vor.
Es kann doch schließlich sein, dass Begleitmaterial in den verschiedenen Regionen unterschiedlich codiert ist.
Ein Hinweisheft z.B., welches u.a. in der EU- & UK-Version englischsprachig ist, aber jeweils unterschiedlichen Auflagen entspringt und verschiedene Codes trägt?

3.
LiquidSnakE hat geschrieben:Kann man machen, muss man aber nicht.
Motoko hat geschrieben:Im Infotext muss es dann aber stehen...
Naja was heißt "muss"?
Hedini hat geschrieben:Wer es eingibt, gibt es ein. Punkt. Die Eingabe des Felds ist freiwillig...
Eben. Was man aber festhalten sollte ist, dass diese Angaben gemacht werden SOLLTEN.
Warum auch nicht? Trägt es doch zur Vollständigkeit der Db bei.
Je mehr (korrekte) Infomationen, desto besser.
Der Bereich der allgemeinen Informationen wird dadurch (zumindest meines Erachtens nach) nicht unübersichtlicher.
Und wer nicht will, der macht halt nicht.

4.
LiquidSnakE hat geschrieben:...des von dir angekreideten Verhaltens "schuldig"...
Ich wollte weder jemandem etwas vorwerfen, noch jemanden beschuldigen oder gar verärgern.
Meine Absicht war lediglich, auf etwas aufmerksam zu machen.

5.
Hedini hat geschrieben:Ich würde gerne den Teil "Produktcode" in eine 1:n-Tabelle ausgelagert sehen..
Wird vermutlich schwer.
Wir würden uns evtl. nicht auf eine angemessene Menge an Unterteilungen einigen können.
Sollten diese so oder so ähnlich vorgegeben sein, wie Motoko es auflistet,
Motoko hat geschrieben:Kartonbox
Schuber
Rückseite Inlay/Box
Spine
Lasche Box (für Gameboy-Spiele z.B.)
ISBN
Garantie-Karte
Werbeflyer
Downloadcode Flyer
oder Flyer allgemein?
Sicherheitshinweise / Konsumentenhinweise
Sonstiges ^^
könnte es systemübergreifend schwierig werden, es sei denn, es stehen wirklich viele zur Auswahl und die nicht verwendeten werden ausgeblendet.
Ausserdem müsste für den Nutzer die Möglichkeit bestehen, Ortsangaben/Kategorien selbst zu betiteln.
Man kann mit den Vorgaben nur schwer alles für alle Systeme abdecken.
Oder es würde sehr viel unter "Sonstiges" fallen.
Manchmal sind z.B. auch mehrere Bedienungsanleitungen dabei. Was sollte man da sonst vorgeben?

Anleitung
Anleitung 2

Was ist, wenn's eine dritte oder noch mehr Anleitungen gibt (wäre glaube ich bei Reihen wie Gold Games oder Konsorten manchmal der Fall)?

Und gibt's da nicht auch evtl. Probleme beim Suchen & Finden?
Keine Ahnung... Zu dem Thema müssten KT & ERASER mal was sagen.

6.
Hedini hat geschrieben:Was jetzt DEN EINEN Produktcode.. bei Nintendo-Spielen angeht..: Das.. "BLAA".. oder der Produktcode auf dem Datenträger.
Also das BLAA auf keinen Fall.
Ob nun "AGB-BLAA-NOE", "AGB-P-BLAA" oder "AGB P BLAA" - BLAA ist in jedem Fall nur ein Teil-Code.
WENN es bei Nintendo den einen Code geben sollte, muss man erstmal abwägen, über was dieser Auskunft geben sollte:
1. Über Spielinhalte/Mediumkontent -> Dann sollte es der Code auf dem Datenträger sein
2. Über das Gesamtpaket/ den Packungsinhalt -> In diesem Fall der Code auf der äussersten Umverpackung (AGB P BLAA, SNSP P BLAA) oder die ISBN

7.
Hedini hat geschrieben:Also ich stimme für eine 1:n-Tabelle für Produktcodes nach o.g. Schema.
Ich für meinen Teil behalte das Code-Feld lieber so bei,
wie es z.Z. ist, weil ich es so für die beste Lösung halte.
Ich kann deinen Wunsch aber nachvollziehen.
Hedini hat geschrieben:Sollte eigentlich nicht länger als 4-8 Stunden dauern...
Dazu kommt aber auch noch die Zeit & der Aufwand, die es benötigt, alle betroffenen Versionseinträge nachzubearbeiten.
Die Zahl derer geht stramm auf die 100.000 zu. Da kommt einiges zusammen.
Wie würde das Code-Feld überhaupt aussehen, wenn der Versioneitrag nach deinem Schema umgestaltet, aber im nachhinein nicht nachbearbeitet wurde?
Z.B. so?

Kartonbox - AGB P A9DE, 1-58416-480-8, 80489.273.US, AGB-A9DE-USA, 80489.133.US
Schuber -
Rückseite Inlay/Box -
Rücken/Spine -
Lasche Box -
ISBN -
Anleitung -
Garantie-Karte -
Werbeflyer -
Downloadcode Flyer -
Sicherheitshinweise / Konsumentenhinweise -
Sonstiges -


Oder auch so?

Verpackung/Inlay - AGB P A9DE, 1-58416-480-8, 80489.273.US, AGB-A9DE-USA, 80489.133.US
Modul -
Anleitung -


Bei einer solchen Umstellung hätten wir mit einem Schlag merkelmäßig viele Falschinformationen in der Db.
Mal abgesehen davon, dass viele der Einträge über Jahre hinweg unangetastet & unberichtigt bleiben würden.
Von daher kann ich mir die Umsetzung deiner Idee beim besten Willen nicht vorstellen, so gut sie auch ist.

MfG
"If you want a vision of the future, imagine a boot stamping on a human face - forever."
-George Orwell-

"Die meisten von ihnen ahnten wahrscheinlich nicht, was sie damit anrichteten, aber die Diener des Ungeheuers wußten sehr wohl, was sie taten.
Und sie leisteten ganze Arbeit.
"

-Jean Raspail-

Benutzeravatar
Hedini
Beiträge: 48
Registriert: Donnerstag, 19. Januar 2006, 16:00
Wohnort: Mönchengladbach
Kontaktdaten:

Re: Hersteller-/ISBN-Code-Feld

#7 Beitrag von Hedini » Dienstag, 1. Dezember 2015, 01:10

Hi,
Bodonator hat geschrieben:Im Gegenteil. Was mich aber gelegentlich verwirrt, ist, dass Codes mal mit /, mal mit , oder mit sonst. Zeichen, manchmal sogar ohne Leerzeichen getrennt werden.
Hm, jo... Freitextfelder sind Datengräber. Unstrukturiert und fehleranfällig.
Bodonator hat geschrieben:
Hedini hat geschrieben:Ich würde gerne den Teil "Produktcode" in eine 1:n-Tabelle ausgelagert sehen..
Wird vermutlich schwer.
Wir würden uns evtl. nicht auf eine angemessene Menge an Unterteilungen einigen können.
Sollten diese so oder so ähnlich vorgegeben sein, wie Motoko es auflistet, könnte es systemübergreifend schwierig werden, es sei denn, es stehen wirklich viele zur Auswahl und die nicht verwendeten werden ausgeblendet.
Es wird auch nicht schwerer als bei den Tabellen für Firmen oder Systeme. Die waren beim Start der OGDB ja auch nicht vollzählig und wer einen Eintrag brauchte, hat einfach gefragt.

Außerdem haben wir ja schon eine dynamische Suche bei der Eingabe von Textfeldern (siehe z.B. die Systemeingabe bei Titeln). Da tippert man drauf los und kriegt Lösungsvorschläge. Ich denke nicht, dass wir über die Zeit sonderlich mehr Stellen für Produktcodes in der zu definierenden Tabelle sammeln werden, als derzeit Systeme in der OGDB sind.
Bodonator hat geschrieben:Man kann mit den Vorgaben nur schwer alles für alle Systeme abdecken.
Oder es würde sehr viel unter "Sonstiges" fallen.
Nö.
Man stellt eine Anfrage an den Admin / ins Forum und gut ist. Ich würde nicht soweit gehen, etwas wie "sonstiges" anzubieten, da sonst unnütze Daten eingegeben werden können. Der Produktcode wäre da, aber der Artikel zu dem er gehört, könnte genauso gut "null" (=nicht definiert) sein.
Bodonator hat geschrieben:Was ist, wenn's eine dritte oder noch mehr Anleitungen gibt (wäre glaube ich bei Reihen wie Gold Games oder Konsorten manchmal der Fall)?
Dreh die Frage mal um... nach was würde der geneigte User suchen?
  • Welchen Produktcode hat Anleitung 2 in Gold Games 8?
  • Welche Versionen haben eine "Anleitung (Day of the Tentacle)" in der Schachtel?
...eher nicht.
Ich würde orakeln, dass es eher Anfragen sind:
  • Welche/n Produktcode/s hat/haben die Anleitung/en in Gold Games 8?
  • Ich habe hier einen Produktcode einer Anleitung, zu welcher Version gehört die (egal die wievielte Anleitung es ist)?
Insofern würde es wohl auch kein Problem darstellen, dass man eine Auflistung bekommt:
Gold Games 8
  • Box - ABC-DEF-777
  • Anleitung - ABC-DEF-Man
  • Anleitung - UIJ-DEG-Man
  • Anleitung - 345-DEH-Man

Bodonator hat geschrieben:
Hedini hat geschrieben:Was jetzt DEN EINEN Produktcode.. bei Nintendo-Spielen angeht..: Das.. "BLAA".. oder der Produktcode auf dem Datenträger.
Also das BLAA auf keinen Fall.
OBJECTION! :mrgreen:
Weil...
Bodonator hat geschrieben:Ob nun "AGB-BLAA-NOE", "AGB-P-BLAA" oder "AGB P BLAA" - BLAA ist in jedem Fall nur ein Teil-Code.
Ich korrigiere mich: Es wäre "AGB-BLAA", nicht "BLAA". :)

AGB = Gameboy Advance
P = Verpackung
NOE = Region
BLAA = Titel des Spiels

AGB-BLAA ist ein Teilcode, aber der Teilcode, der DEN EINEN Produktcode darstellen könnte: Alles andere ist konkret und AGB-BLAA ist das abstrakte "Spiel". Wenn ich über "Alone in the Dark" mit einem Japaner rede, wird der auch CGB-BIDP auf seiner Verpackung finden ungeachtet der Region und ungeachtet des Re-Release. Bei NES-Spielen werden bspw. oft EEC-Verpackungen mit -FRG oder -FAH Anleitungen zusammengepuzzelt und sämtliche Releases in der EU laufen unter demselben Barcode.

AGB-BLAA wäre demnach der kleinste, gemeinsame Nenner, wobei ich diese Diskussion eigentlich nicht weiter verfolgen möchte, da ich aktuell Kopfschmerzen von Nintendo-Produktcodes bekomme :wallbash: und dies für uns alle eh keine Lösung darstellt.
Bodonator hat geschrieben:Dazu kommt aber auch noch die Zeit & der Aufwand, die es benötigt, alle betroffenen Versionseinträge nachzubearbeiten.
Die Zahl derer geht stramm auf die 100.000 zu. Da kommt einiges zusammen.
Und wenn man es nicht macht, geht die Zahl dann irgendwann stramm auf die 200.000 zu.
Wenn man das aktuelle Feld einfriert und auf eine andere Datenhaltung umschaltet, bleibt die Zahl bei 100.000 und wird stetig kleiner. Niemand hat gesagt, dass ein Datenbankdesign beim Start einer Lösung perfekt sein muss und gleichzeitig sollte jeder, der eine bessere, nachhaltigerere Lösung findet laut "HIER!" schreien.

Klar, es ist immer ein Krampf ein Freitextfeld aufzutrennen, aber Unordnung beibehalten, weil man den Aufwand scheut aufzuräumen?

Bodonator hat geschrieben:Wie würde das Code-Feld überhaupt aussehen, wenn der Versioneitrag nach deinem Schema umgestaltet, aber im nachhinein nicht nachbearbeitet wurde?
Z.B. so?

Kartonbox - AGB P A9DE, 1-58416-480-8, 80489.273.US, AGB-A9DE-USA, 80489.133.US
Schuber -
Rückseite Inlay/Box -
Rücken/Spine -
Lasche Box -
ISBN -
Anleitung -
Garantie-Karte -
Werbeflyer -
Downloadcode Flyer -
Sicherheitshinweise / Konsumentenhinweise -
Sonstiges -

Oder auch so?

Verpackung/Inlay - AGB P A9DE, 1-58416-480-8, 80489.273.US, AGB-A9DE-USA, 80489.133.US
Modul -
Anleitung -
Nein, so:
Produktcode - AGB P A9DE, 1-58416-480-8, 80489.273.US, AGB-A9DE-USA, 80489.133.US
Produktcodes: AGB P A9DE (Verpackung), AGB-A9DE-USA (Modul)

Produktcode = altes Feld bleibt auf Formular, speichern auf dem Feld wird nur erlaubt, wenn der neue Wert null, also "leer" ist
Produktcodes = neuer Bereich auf dem Formular, ähnliches Verhalten wie derzeit "Kopierschutz" in der OGDB. Nur die erste Dropdownbox müsste dann das Freitextfeld für den Code werden. Beide Werte müssen angegeben werden (Code + Ort), sonst ist ein Speichern nicht möglich.
Bodonator hat geschrieben:Bei einer solchen Umstellung hätten wir mit einem Schlag merkelmäßig viele Falschinformationen in der Db.
Mal abgesehen davon, dass viele der Einträge über Jahre hinweg unangetastet & unberichtigt bleiben würden.
Von daher kann ich mir die Umsetzung deiner Idee beim besten Willen nicht vorstellen, so gut sie auch ist.
Soll ich mal ein Mockup erstellen, damit wir Bilder haben über die wir uns unterhalten können? :)

Schöne Grüße,
Hedini
Also ich stimme für eine 1:n-Tabelle für Produktcodes nach o.g. Schema. :respekt:

Benutzeravatar
Motoko
Heilige
Beiträge: 2051
Registriert: Samstag, 15. Oktober 2005, 17:58
Wohnort: Hengasch, Landkreis Liebernich

Re: Hersteller-/ISBN-Code-Feld

#8 Beitrag von Motoko » Dienstag, 1. Dezember 2015, 17:33

Bodonator hat geschrieben:Also ich bin mal so frei, KT an dieser Stelle zu zitieren...
Ups, also das habe ich wohl irgendwie nie mitbekommen oder auch erfolgreich verdrängt :oops:
Bild

Bild Bild

Benutzeravatar
ERASER_M
OGDB Tech
Beiträge: 1334
Registriert: Montag, 30. April 2007, 15:56
Wohnort: Hessen
Kontaktdaten:

Re: Hersteller-/ISBN-Code-Feld

#9 Beitrag von ERASER_M » Dienstag, 1. Dezember 2015, 18:00

@ Hedini

so schön eine solche zusätzliche Tabelle (ähnlicher der Kopierschutz Felder) wäre. Es wäre ein riesiger Aufwand die verschiedenen, bestehenden Einträge später entsprechend anzupassen.

Aktuell haben wir (leider) schon verschiedene Methoden der Eintragung. Der eine trägt im Feld nur die "wichtigen" Angaben wie z.B. Außenbox, Datenträger ein, der andere haut alle Angaben (mit oder ohne Beschreibung) in das Feld. Andere wiederum tragen die Angaben nur bei der weiteren Beschreibung ein oder bei beidem etwas...

Hieraus dann mit einer neuen Tabelle die entsprechenden Einträge zu finden und anzupassen, würde vermutlich Jahre dauern :mrgreen:

Ich persönlich wäre (erstmal?) für eine einheitliche Lösung mit dem jetzigen Feld. Wie genau (ob mit oder ohne Begrenzung und der Rest (= "unwichtiges") dann in die Beschreibung müsste man dann noch ausdiskutieren.
Bild

Benutzeravatar
Hedini
Beiträge: 48
Registriert: Donnerstag, 19. Januar 2006, 16:00
Wohnort: Mönchengladbach
Kontaktdaten:

Re: Hersteller-/ISBN-Code-Feld

#10 Beitrag von Hedini » Dienstag, 1. Dezember 2015, 19:09

@ ERASER_M, Bodonator

Ganz ehrlich: Ich verstehe Euer Problem nicht.

Die Situation ist folgende:
1. Das Datenbankdesign hat den Fall anfangs nicht abgebildet
2. Es sind unstrukturierte Daten in ein Feld gelaufen
3. Das Feld ist derzeit nur bedingt aussagekräftig

Lösung 1 (Null-Option: Do nothing)
1. Alles bleibt beim alten
Pro:
+ Kein Zeitaufwand
Contra:
- Feld ist nicht aussagekräftig
- Anzahl verschwurbelter Datensätze wächst weiter an
- diverse Suchanfragen von Sammlern (siehe oben) nicht abbildbar

Lösung 2 (Minimum-Option: Do minimum)
1. Anleitung rausgeben, wie das Feld richtig zu benutzen ist
Pro:
+ kleiner Zeitaufwand (ca. 1,00 Std.)
Contra:
- alle Datensätze müssen bereinigt werden, um der Anleitung zu entsprechen
- Gefahr besteht, dass die Anleitung nicht gelesen / befolgt wird (Sanktionen nötig?)
- Feld nur schwach aussagekräftig
- diverse Suchanfragen von Sammlern (siehe oben) immer noch nicht abbildbar

Lösung 3 (Minimum-Plus-Option: Do something / ohne "Speichern verhindern, wenn Produktcode nicht null")
1. Das bestehende Feld einfrieren (HTML-Attribut "readonly" setzen und fertig)
2. Neue Datentabelle "Produktcodes" erstellen
3. Neue Lookup-Tabelle "Produktcodeorte" erstellen
4. Lookup-Tabelle mit ca. 20 Datensätzen bevölkern für den 1. Wurf
5. Datentabelle ins Formular einbinden
6. Suche anpassen, dass sowohl das alte Feld "Produktcodes" als auch die neue Tabelle durchsucht werden
7. Fertig
Pro:
+ Datenbankdesign ist normalisiert
+ Orte der Produktcodes sind nachvollziehbar
+ gezielte Suchen sind möglich
+ bestehende Lösung wird mit lesendem Zugriff beibehalten und sukzessive abgeschaltet
+ es laufen sofort keine unstrukturierten Daten mehr in das Produktcode-Feld
Contra:
- mehr Mausklicks zum Eingeben der Produktcodes
- höherer, aber degressiv verlaufender Verwaltungsaufwand für die Lookup-Tabelle
- mäßiger Anpassungsaufwand (ca. 4,00 - 8,00 Std.)

Habe ich da ein Killer-Argument gegen Lösung 3 übersehen?

Ja, die Daten müssen im Verlaufe der nächsten Jahre bereinigt werden.
Das werden die auch schon bei Gameboy-Spielen, die ich in den letzten Wochen in eigene Titel ausgegliedert habe.
Das werden die auch, wenn höher auflösende Screenshots hochgeladen werden.
Und das werden die auch, wenn Sonderzeichen im Barcode sind.

So what?
Jeder bemängelt das Feld aufgrund von Fehlbedienung anderer, aber keine möchte diese Fehlentwicklung stoppen oder besser:"in geordnete(re) Bahnen lenken", weil dann ja jemand (anderes?) die Daten geradeziehen müsste.

Wer sagt, dass die Daten von heute auf morgen im neuen Format da sein müssten, oder dass man als Admin/Support/erfahrener User alles selbst machen muss? Das hat doch Zeit, liebe Leute. :tee:
:respekt:

Das alte Feld ist ja nicht weg, nur sollte die Dateneingabe dort verhindert werden zugunsten zweier neuer Tabellen (siehe oben).


Schöne Grüße,
Hedini

P.S.: Ich könnte mich viel eher darüber aufregen, dass in der OGDB noch keine Referenzen von NES-Versionen auf den Vertrieb "Bienengräber" existieren. :wink:
Also ich stimme für eine 1:n-Tabelle für Produktcodes nach o.g. Schema. :respekt:

Benutzeravatar
Bodonator
Beiträge: 197
Registriert: Dienstag, 18. Mai 2010, 15:11

Re: Hersteller-/ISBN-Code-Feld

#11 Beitrag von Bodonator » Sonntag, 20. Dezember 2015, 15:23

Hedini hat geschrieben:Niemand hat gesagt, dass ein Datenbankdesign beim Start einer Lösung perfekt sein muss und gleichzeitig sollte jeder, der eine bessere, nachhaltigerere Lösung findet laut "HIER!" schreien.
Selbstverständlich!
Hedini hat geschrieben:Wenn man das aktuelle Feld einfriert und auf eine andere Datenhaltung umschaltet, bleibt die Zahl bei 100.000 und wird stetig kleiner.
Richtig, aber man kann nicht garantieren, dass sie auf 0 fallen wird, schon garnicht, dass dies in kürzester Zeit geschieht.
Ich schätze mal, das dies der springende Punkt ist.
ERASER_M hat geschrieben:Ich persönlich wäre (erstmal?) für eine einheitliche Lösung mit dem jetzigen Feld.
Öh, also falls diesbezüglich eine Änderung eintreten kann/soll, sollten wir uns schleunigst auf eine langfristige Lösung einigen, sonst steigt der Arbeitsaufwand und die, nach dem zu beschliesenden Verfahren quasi als unkorrekt zu bezeichnende Einträge bis dahin weiter und weiter an.
ERASER_M hat geschrieben:Wie genau (ob mit oder ohne Begrenzung und der Rest (= "unwichtiges") dann in die Beschreibung müsste man dann noch ausdiskutieren.
Ja?
KT hat geschrieben:...bitte Details beim Herstellercode im normalen Text unterbringen und im Feld selber nur die Codes. ...
...ja, das gilt eigentlich immer noch...
Also wenn auch da noch was diskutiert werden muss, denn sollte auch dies schnell geschehen.
Mir ist es egal, wie es gemacht wird, nur hauptsache, es werden verbindliche Entscheidungen getroffen..
Ob Ortsangabe ins Code-Feld oder ins Infofeld, is mir beides recht.
Ich habe selber jahrelang die Ortsangabe im Code-Feld untergebracht, bis mich im Frühjahr 2013 KT anschrieb.
Mir viel damals auch alles aus'm Gesicht, bei dem Gedanken, wieviele meiner Einträge ich nun nachzuarbeiten hatte (und z.T. immernoch habe).
Ich möchte nur wissen, woran ich bin, bevor ich meine Arbeit in der Db wieder aufnehme.
Hedini hat geschrieben:3. Das Feld ist derzeit nur bedingt aussagekräftig
Wenn in dem Feld nichts anderes als eine Aufzählung der Codes erfolgen soll, wie KT schreibt, dann nicht.
Was dagegen ungenügend ist, ist die Beschreibung im Wiki unter Punkt 3.2 - Hersteller-/ISBN-Code & Barcode.
Hedini hat geschrieben:Ich verstehe Euer Problem nicht.
Ich habe kein wirkliches Problem, ich wollte dir nur aufzeigen, warum diejenigen in der Db, die so etwas zu entscheiden/durchzuführen haben, sich vermutlich dagegen ausprechen werden.
Anfangs hatte ich es auch so verstanden hatte, dass, zwischen der Umstellung nach deiner Art und dem Nachbearbeiten der Einträge, in diesen 'Unkorrektheiten' (welche zu vermeiden sind) stehen und/oder die Codes unübersichtlich gelistet werden.
(Nebenbei, ich verstehe nix von Programmierung. Kann in diesem Fall nicht viel mit Begriffen wie z.B. Formular anfangen. Brauchst mir aber auch nichts erklären, da ich es nicht bin, den/die es zu überzeugen gilt.)
Meines Erachtens gibt es kein Killerargument gegen deine Lösung 3.
Im Gegenteil, ich finde sie sinnvoll.
Da es allerdings alle Einträge, die Codes in dem Feld tragen betrifft und dadurch ein extremer Arbeitsaufwand entsteht, den es glaube ich bis jetzt in der Db noch nicht gab, gehe ich aber dennoch bis auf weiteres davon aus, dass sie nicht umgesetzt wird.

Zu deiner Lösung 2:
Anleitung formulieren und veröffentlichen, sprich: Tutorial anpassen wäre Punkt 2.
Punkt 1 ist erstmal, sich zu einigen.
Kann ja sein, dass jemand das erstmal mit KT ausdiskutieren möchte?
Liquid z.B. war ja not so amused.
Von daher wäre es astrein, wenn sich mehr Leute hier im Thread beteiligen würden...
Hedini hat geschrieben:Contra:
- alle Datensätze müssen bereinigt werden, um der Anleitung zu entsprechen
Nein, nur die, die neben Codes & Trennzeichen noch weiteres enthalten.
Hedini hat geschrieben:- Gefahr besteht, dass die Anleitung nicht gelesen / befolgt wird (Sanktionen nötig?)
Ja klar besteht die Gefahr. In diesem Fall würde der entsprechende Nutzer über kurz oder lang angeschrieben werden (zumindest, wenn Administration & Support bescheid wissen, was wohl der Fall sein wird, sollte dieser Thread seinen Zweck erfüllen).
Solange im Tutorial steht, was Sache ist, kann man sich ja darauf berufen.
Ausserdem würden bei einer solchen Umstellung bestimmt auch Ankündigungen hier im Forum und unter Neuigkeiten in der OGDb erfolgen.
Was meinst du mit Sanktionen?
Hedini hat geschrieben:Jeder bemängelt das Feld aufgrund von Fehlbedienung anderer...
Ich nicht. Ich bemängel auch nicht vermeintliche Fehlbedienung anderer.
Woher sollten die es denn besser wissen, wenn nicht durch PMs oder diesen Thread?
Hedini hat geschrieben:...keine möchte diese Fehlentwicklung stoppen oder besser:"in geordnete(re) Bahnen lenken", weil dann ja jemand (anderes?) die Daten geradeziehen müsste.
Doch. Dazu habe ich ja diesen Thread erstellt.
Und ich habe auch kein Problem damit, viele, viele andere Einträge (sinnvoll/strukturiert) zu berichtigen.
Bei meiner eigentlichen Arbeit stoße ich andauernd auf zu berichtigende Einträge, welche ich auch bearbeite, solange ich die Zeit dazu habe.
Habe ich diese, machen Berichtigungen einen Großteil meiner Arbeit aus.

Auch bin ich gerne bereit, bei einer solchen Umstellung verstärkt mitzuhelfen,
den zu-erledigen-Stapel an Einträgen mit abzuarbeiten.
Dabei möchte ich noch anmerken, dass ein einfaches Zugreifen auf betroffene Einträge durch die Unvollständige Inhalte-Seite ermöglicht werden sollte, falls machbar.
Wenn jene Einträge aber einfach über die Suchfunktion gefunden werden können, kann man dies ja aussparen.
Hedini hat geschrieben:Soll ich mal ein Mockup erstellen, damit wir Bilder haben, über die wir uns unterhalten können?
Kannst du gerne. Warum nicht?
Nur allein für mich brauchst du das aber nicht, da ich, wie gesagt, nicht derjenige bin, den es zu überzeugen gilt.
Mir ist wurscht, ob das Feld umgestaltet wird oder nicht.
Nur sollte es das, müsste es m.E. schnell entschieden und umgesetzt werden.
Wenn du Bilder posten möchtest am besten via Link zu Imageshack oder so.

Das hier sollte auch nicht vergessen werden:
Motoko hat geschrieben:Würde es erst mal helfen, wenn man bei der Suchfunktion auch das Feld "Weitere Informationen/Inhaltsbeschreibung:" mit einbezieht?
Diese Funktion wäre in jedem Fall in meinem Interesse, ob nu als Ersatz-/Übergangslösung oder nicht.
Da spreche ich mich mal für aus.


Mein erster Gedanke war, erstmal in der Db keine Einträge zu verfassen, bzw. zu verbessern, bis die beiden Punkte
1) Wird das Code-Feld umgestalltet? Und
2) falls nicht, dann Codes oben rein, Ortsangabe unten rein?
abschließend geklärt und ggf. Wiki/Tutorial angepasst wurde, da ich keine Lust habe, andauernd vermeidbare 'Unkorrektheiten' zu verbessern.
Aber ich schätze mal, das hier wird sich noch 'ne ganze Weile hinziehen, weswegen ich mich bis auf weiteres nach KTs Ansage richte:
Codes oben rein, Ortsangabe unten rein.


MfG
"If you want a vision of the future, imagine a boot stamping on a human face - forever."
-George Orwell-

"Die meisten von ihnen ahnten wahrscheinlich nicht, was sie damit anrichteten, aber die Diener des Ungeheuers wußten sehr wohl, was sie taten.
Und sie leisteten ganze Arbeit.
"

-Jean Raspail-

Benutzeravatar
Motoko
Heilige
Beiträge: 2051
Registriert: Samstag, 15. Oktober 2005, 17:58
Wohnort: Hengasch, Landkreis Liebernich

Re: Hersteller-/ISBN-Code-Feld

#12 Beitrag von Motoko » Donnerstag, 4. Februar 2016, 13:24

Würde so ein Satz im Tutorial erst mal helfen?:
Details zum Herstellercode (wie zum Beispiel deren Platzierung) sollten nach Möglichkeit nicht hier, sondern unten bei "Weitere Informationen/Inhaltsbeschreibung:" erfolgen.
Ich gebe zu: das ist jetzt ein wenig kleinlaut ("nach Möglichkeit"), weil ich es ja auch sehr oft nicht so gemacht habe. Und weil: z.B. Suche mit "Modul" = "2318 Versionen entsprechen diesen Kriterien" - Mist! :blueeye:
Bild

Bild Bild

Antworten