Hallo Jakob,
Ist erledigt. Ich hab jetzt einiges was ich noch in Vorbereitung hatte ins Wiki eingestellt. Es ist nochnichtfertig, zeigt aber meinen bisherigen Stand. Die Beschreibung von Arten von Teilen heisst bei mir „Kategorienliste“ und ist im Wiki zu finden unter
http://wiki.opensourceecology.de/wiki/Systematik_für_Bauteile
Natürlich können da bei Bedarf und so nach und nach noch jede Menge weiterer Kategoriengruppen, Haupt- und Unter-Kategorien ergänzt werden. Der bisherige Stand der Liste entspricht ungefähr dem, was ich im Kopf hatte, als noch „nur“ um ein Baukastensystem ging. Inzwischen geht es aber darum, jedes nur irgendwie erdenkliche Bauteil dort eingliedern zu können. Daraus ergeben sich doch einige neue qualitative Anforderungen und ich bin mir inzwischen nicht mehr so sicher, ob das überhaupt möglich ist. Solange man nur von einem Metallbaukasten ausging konnte man recht einfach mit ein paar Kategoriengruppen alle Anforderungen abdecken, also eine mehr oder weniger umfassende (oder bei Bedarf zu ergänzende Liste) vordefinieren. Seit ich darüber nachdenke, wie man das auf *alle erdenklichen" Bauteile ausdehnen könnte, ist mir erst mal so richtig bewusst geworden, wieviele und insbesondere Spezialbauteile es gibt, bei denen ich Mühe hätte, die einer sinnvollen Kategorie zuzuordnen. Man braucht nur mal irgendein Küchengerät auseinanderzunehmen. All die ganzen Spritzguss-Teile, Spezialhalterungen usw. Das Hauptproblem, soweit ich bislang erkennen kann, besteht auch nicht nur darin, sich eine sinnvolle Kategorie auszudenken, oder ihr ein bestimmtes Bauteil logisch/sinnvoll zuzuordnen. Sondern der Anwender muss auch hinterher imstande sein, ein gewünschtes oder benötigtes Bauteil anhand dieser Zuordnung aufzuspüren. Und was mir logisch und sinnvoll erscheint kannbei ihm einer anderen Logik folgen, oder besser gesagt: Bei solchen Zuordnungen gibt es keine Ein-Eindeuigkeit, weil viele Bauteile aufgrund ihrer Eigenschaften durchaus in mehrere Kategorien passen könnten. Z.B. kann ein kleines weisses Plastikteil aus meinem Küchengerä in die Kategorie „Zahnrad“ passen oder auch in die Kategorie „kleine össelige Plastik-Teile“
Eine einheitlichen Identifikation von Teilen stelle ich mir ähnlich vor wie bei Lego, da hat jedes Teil eine Nummer und es gibt verschiedene Datenbanken und Bezugsquellen, siehe z.B. > http://www.peeron.com/
Danke, ein sehr schönes Beispiel. Hier sind wir allerdings wieder auf der Ebene meiner ursprünglichen Baukastenidee, und zwar genau bei dem, was ich als „Set“ bezeichne, d.h., ich kann eine bestimmte Summe von Bauteilen einem Set zuordnen bzw. ein Set dadurch definieren, welches thematisch einen bestimmen Zweck erfüllt (etwa: Ich kann mit dem Set „Bagger“ einen Lego-Bagger bauen; dabei können einzelne der hier benötigten Bauteile natürlich auch in anderen Sets Verwendung finden).
Auf dieser Ebene ist es noch relativ einfach Kategorien für die Bauteile zu definieren, weil die Gesamtmenge noch relativ gut überschaubar und ihre Gesamtzahl nicht so unendlich groß ist. Wenns also nur um den Baukasten ginge, dann wäre die Vorgehensweise wohl soweit klar : Einfach einige Haupt-Unviversalbauteile definieren, bei Bedarf weitere hinzufügen, auf dieser Basis Sets definieren und bei Bedarf Spezialbauteile hinzufügen. Das ist so in etwa der Weg den Lego und andere Baukastenhersteller in ihrer Historie vollzogen haben, die haben ja nicht gleich von Anfang an den heutigen Umfang an Bauteilen gehabt.
Wenns aber um die Anwendung der Systematik für Stücklisten und beliebig umfangreiche Bauteilekataloge geht, dann ist es leider nicht mehr so einfach, wie mir inzwischen immer klarer wird. Ich hoffe ich hab da am Anfang den Mund nicht zu voll genommen, denn es wäre schön, wenn man damit auch die Stücklisten erschlagen könnte.
Hallo case, ich habe mir jetzt den ursprünglichen Thread durchgelesen und möchte nur ein Missverständnis klären: bei der Entwicklung einer Systematik (d.h. ein System was für Arten von Teilen mit was für Arten von Parametern) sind die Notationen (d.h. wie du die Nummber/Zeichenfolgen/Identifikatoren zusammensetzt) erstmal zweitrangig! Ich habe den Eindruck du verzettelst dich da etwas.
Da gebe ich Dir recht. Ich hab das für mich nur erstmal als eine Art nächstliegenden roten Faden benutzt, um mich in die Sache reinzudenken und überhaupt irgendwie damit anzufangen. Sobald man sich damit näher auseinandersetzt kommt man dann schnell auf einige grundlegende Probleme.
Bezüglich der Notation / TeileNr.-Aufbau hatte ich z.B. ursprünglich zwei Gedanken, die ich wenn möglich umsetzen wollte:
-
Die Teile-Nummern sollten möglichst kurz sein.
-
Durch die Vewendung von Buchstaben als Bestandteil hatte ich die Hoffnung, das man durch Abkürzungen sozusagen anhand der Teile.Nr. schon einen Hinweis auf die Art des Bauteils kriegen könnte, also etwa WI für Winkelstück, sowas in der Art. Man könnte das vielleicht auch als „sprechende“ Nummern bezeichnen, etwa so ähnlich, wie in Firmen mithilfe bestimmter Nummernkreise bei Artikelnummern bestimmte Produktgruppen definiert werden können.
Von beiden Gedanken hab ich mich inzwischen getrennt, das wäre schon auf der Baukastenebene nicht gegangen, aber bei einer universellen Systematik gehts erst recht nicht. Ich erwähne dies auch nur als Beispiel um zu illustrieren, wie ich durch die Beschäftigung mit der Notation recht schnell auf die inhaltlichen subtileren Probleme gestoßen bin.
Wesentlich sind für die Bauteile erstmal Fragen wie
- Was für grundlegende Arten von Bauteilen sind sinnvolle (z.B. Zahnrad, Welle, Schraube, Blech, Winkel…)?
- Welche grundlegenden Eigenschaften haben die jeweiligen Bauteilarten (z.B. Länge, Anzahl von Zähnen, Löchern etc.)?
- Welche sinnvollen Werte kommen in den jeweiligen Eigenschaften vor (z.B. Vielfache von 10mm, etc.)?
Ja, siehe dazu auch den Link im Wiki. Die Grundidee ist, das jedes Bauteil natürlich eine unique ID-Nr. bekommt. Es muss aber nicht für jedes Bauteil bzw. inbesondere solche die sich nur in einem Parameter-Wert wie Länge oder Anzahl Löcher unterscheiden bzw. eine fortlaufende Reihe bilden, auch ein eigenes Datenblatt existieren, sondern die können in einem gemeinsamen Datenblatt erfasst bzw. zusammengefasst werden, um Redundanzen zu minimieren.
Wie für die Systematik dann mit Nummern, Buchstaben und anderen Zeichen eine sinnvolles Notationssystem zusammengesetzt wird, sollte erst im Zweiten Schritt geklärt werden und ist davon unabhänig. Dies als Hinweis eines Informationswissenschaftlers, der sich eingehender mit der Erstellung von Systematiken beschäftigt hat
Ja, darin stimme ich Dir auch zu, soweit das die „ursprüngliche Baukastenebene“ betrifft. Was die „Stücklistenebene“ betrifft, da werden ja keine konkreten Bauteile oder Kategorien mehr vorgegeben, d.h., genauer gesagt müssen da beliebige davon sinnvoll untergebracht werden können und dazu ist es erforderlich sich über abstrakte und formale Aspekte der Systematik selbst im Klaren zu werden sowie über pragmatisch-technische Aspekte des Systems in seiner Anwendung. ( Wobei aber auch hier Dinge wie die Notation eine völlig untergeordnete Rolle spielen, insofern hast Du schon recht und kann die Notation so wie bislang beschrieben als etwas Vorläufiges betrachtet werden, das später gerne noch beliebig geändert und angepasst werden kann. )
Was mir im Moment am meisten Kopfzerbrechen bereitet und für mich auch die Frage aufwirft, ob das Ganze überhaupt geht und machbar ist, das fällt in den pragmatisch-technischen Bereich und ist schlicht die Frage nach der Navigierbarkeit. Und wie man eine solche als Anwendung technisch umsetzen könnte.
Lass uns mal an eine Datenbankanwendung denken, welche auf Anforerung dynamisch einen „browsbaren“ (=navigierbaren) Baueilekatalog bereitstellt. Das System muss dabei drei Anforderungen erfüllen (und genau die bereiten mir Kopfzerbrechen):
-
Es muss für einen User, der ein neues Bauteil eingeben will möglich sein, dieses möglichst eindeutig und zielgerichtet einer bestimmten Kategorie zuzuordnen
-
damit ein anderer User, der nach einem Bauteil in dieser Art sucht, dieses auch tatsächlich später ebenso eindeutig und zielgerichtet wieder rausfischen kann.
-
Das ganze sollte möglichst schnell gehen. Es macht keinen Sinn wenn man sich erst durch eine Indexliste mit 9999 Kategoriengruppen durchhangeln muss, um zu entscheiden, welche nun am besten passt.
Das klingt zwar auf den ersten Blick recht einfach, die Kategorien müssten lediglich in einer hierarchischen Baumstruktur angeordnet sein, damit man da schnell durchnavigieren und vom allgemeinen auf immer spezifischere Kategorien kommen kann. Ist auch prinzipiell richtig, aber ich habe halt das Problem, was ich schon eingangs mit dem Küchenbauteil beschrieben habe: Was ist wen sich ein Bauteil nach seiner Art und Charakter durchaus in mehreren Kategorien unterbringen lässt ? Für ein Stück an dem ein Motor befestigt werden kann kann ich zunächst unter der Kategoriengruppe „Motoren“ und Hauptkategorie „Zubehör“ suchen (oder „Befestigungsmaterial“) oder aber auch unter der Kategoriengruppe „Blechwinkel“.
Man könnte vielleicht auch eine Spezial-Kategorie einführen, die nicht auf die Eigenschaften eines Bauteils näher eingeht, aber auf die Zugehörigkeit zu einer Maschine. Also etwa eine Kategorie für alle Bauteile von OSE-Maschinen. Oder zumindest für solche Bauteile von OSE-Maschinen, die nicht so einen starken Standard-Charakter haben, das man sie inuitiv eher in einer anderen Kategorie einordnet, wie z.B. eine M8-Mutter.
Ein anderer, technischer Aspekt ist die Ergonomie beim Browsen und navigieren des Katalogs. Es sollte m.E. zu einem Bauteil ausser der Zeichnung mit allen Maßen usw. auch eine Art Thumbnail existieren, der beim Browsen mit eingeblendet wird, etwa so, wie das auch bei Deinem Lego-Link der Fall ist und schön umgesetzt wurde.
Techische Realisierung wäre also wohl ein kleines .jpg oder .png-Bildchen, welches irgendwo auf dem Server abgelegt wird und im Datenbankeintrag dazu wird der Bilddateiname hinterlegt, damit hinterher bei der dynamischen Generierung der entsprechenden Katalogseite das Thumbnail mit eingeblendet werden kann.
Damit eine größere Anzahl von solchen Bildern relativ schnell in eine Katalogseite eingeblendet werden kann und das ganze auch einigermaßen hübsch aussieht, sollten die Bildchen natürlich ein einheitliches Format haben, etwa 300x300 Pixel, und auch nicht allzu groß sein. Was ist nun aber, wenn mein Bauteil etwas größer und komplexer ist, als das ich es in so einem Thumbnail noch leserlich unterbringen kann ?
OK, wir haben also einen Server, auf dem eine Datenbank läuft und wo in einem Verzeichniss Thumbnail-Bilder liegen. Vielleicht liegen in einem anderen Verzeichniss auch noch die Datenblätter mit den detaillierteren Maßzeichnungen. Jetzt ist die Frage: ist das der einzige Server weltweit ? Wenn unser Bauteilekatalog so etwas wie einen Standard darstellt, dann wollen vielleicht andere Leute diesen Katalog auch auf ihrem Server haben oder sich zumindest en kompletten Inhalt irgendwie runterladen können (vielleicht als .pdf ?), also so ähnlich, wie ich mir einen snapshot von Wikipedia auf mein Notebook runterladen kann und damitnetzunabhängig bin. Falls es aber mehrere Server gibt, wie funktioniert dann der Abgleich untereinander ? OK, sagen wir , es gibt nur einen Zentralserver, wo neue Bauteile eingegeben werden können, alle andern ziehen sich davon dann ggflls. ein Snapshot oder sowas.
Jezt zur Eingabe: Wie stellt man sicher, dass nicht irgendein Hirni da einen völligen Quatsch eingibt ? Man könnte dies vielleicht manuell durch eine Art Review-Prozess machen. Bzw. dann vielleicht auch gleich durch die Person des Reviewers eine (möglichst) sinnvolle Einordnung des Bauteils in eine Kategorie vornehmen lassen, immerhin könnte jemand, der das öfters macht sich vielleicht besser in der Masse der Kategorien auskennen und eine bessere Zuordnung vornehmen. Allerdings wäre dies wieder mit personellem Aufwand verbunden, das System würde icht völlig automatisch funktionieren. Andererseits wäre das aber vielleicht auch ok, es könnte sogar sein, das das genau eine Art von Tätigkeit wäre, auf die sich jemand der weder Ingenieurs- noch E-Technik- oder sonstige Skills hätte, spezialisieren könnte und es zu seiner Aufgabe machen könnte, dass, wenn irgendwo auf der Welt eine neue OSE-Maschine entwickelt worden ist, deren BOM abgearbeitet wird und alle bis dato noch nicht in der Datenbank vorhandene Bauteile davon dann eingepflegt werden.
OK, das sind jetzt weniger Sachen, die mit dem Aufbau der Systematik an sich und direk zu tun haben, aber ich sagte ja, das mich in dem Zusammenhang auch pragmatisch-technische Aspekte beschäftigen und dazu gehört halt auch eine konkrete (Datenbank-)Anwendung, die den Zugriff ermöglicht sowie die Dateneingabe.
Ich glaube bis hierher wird zumindest eines schon deutlich: Der inhaltliche und formale Aufbau der Systematik ist eine Sache und nötig um einen entsprechenden Rahmen vorzugeben (schliesslich muss ich ja an irgendeiner Stelle mal meine Datenbanktabellen und Strukturen definieren und dafür brauche ich das). Das ganze in Form einer konkreten Anwendung nutzbar zumachen ist aber nochmal eine ganz andere Sache und mit Sicherheit mit nicht geringem Arbeitsaufwand verbunden.
Die Frage ist, will man das und lohnt sich das ? Oder wäre das vielleicht sogar eher ein eigenständiges Projekt ? Übrigends, drüben bei OSE-US haben die sich auch schonmal Gedanken über eine Art Bauteile-Datenbank gemacht, ich hab aber grad keinen Link dazu parat und weiss auch nicht, wie weit die inhaltlich dabei gehen.
Falls man den Aufwand nicht treiben will und sich stattdessen wieder zurück begibt auf die Baukasten-Ebene wäre alles ziemlich easy. Einfach manuell ein paar benötigte Grundkategorien definieren plus ein paar Unterkategorien, später bei Bedarf noch ergänzen, und dann kann man ganz nach eigenem Gusto schon anfangen, Standard-Bauteile zu beschreiben und damit schonmal das eine oder andere Baukasten-Set definieren. Und diese dann auch bei Bedarf ergänzen.
Ja, soweit das, was mich in diesem Zusammenhang bewegt, ich bin im Moment im Zweifel, was der beste Weg wäre, daher sind mir Meinungen, Standpunkte und Anregungen grad sehr willkommen. Speziell auch Dein Feedback, Jakob, welches mich im Moment wieder stärker zur reinen Baukastenebene tendieren lässt. Andererseits wäre die Stücklisten-Sache wirklich sehr nice to have, darum möchte ich das nicht einfach so beim ersten auftauchen von ein paar Problemchen übern Haufen werfen und aufgeben.
Gruss, Oliver