Entwicklung neues Brau-Dateiformat - BeerJSON

Hier kommt alles rein, was woanders keinen Platz hat.
Antworten
Benutzeravatar
chaos-black
Posting Freak
Posting Freak
Beiträge: 3318
Registriert: Dienstag 10. Juli 2012, 21:38
Wohnort: Berlin
Kontaktdaten:

Entwicklung neues Brau-Dateiformat - BeerJSON

#1

Beitrag von chaos-black »

Bin gerade bei Reddit darüber gestolpert, dass Programmierer/Softwareentwickler, die mit BeerXML unzufrieden sind, daran sind ein BeerJSON Dateiformat zu bauen. Ich hab keine Ahnung davon, dachte mir aber, dass bei der großen IT-Fraktion hier das sicher jemand interessant findet:
https://www.reddit.com/r/Homebrewing/co ... beerxml_2/

Damit man weiß worum es genauer geht zitiere ich mal den Eingangspost davon:
Hi,

Looking at this tread https://www.reddit.com/r/Homebrewing/co ... a/dohp4a4/ I learned that there is a lack of modern brewing data exchange standard. BeerXML 1.0 is popular, but limited. BrewXML 2.0 never really got off the ground. We decided to do something about it. These days JSON is more popupar as a data medium than XML. So BeerJSON it is.

Introducing https://github.com/beerjson/beerjson

Instead of creating formal standard board, we propose to do this in a github repo. Schema defined as JSON Schema http://json-schema.org/, different standard versions are in different branches https://github.com/beerjson/beerjson/tree/beerjson-1.0. Change proposals are pull requests https://github.com/beerjson/beerjson/pulls. Issues https://github.com/beerjson/beerjson/issues can be reported. There is a gitter chatroom https://gitter.im/beerjson/beerjson

Current state: We have converted BeerXML 2.01 as described in PDF here http://users.speakeasy.net/%7Eantonw/be ... _v2_01.pdf to JSON Schema definition, wrote some tests and created CI workflow that runs tests automatically. Obviously there are errors, to be useful it needs to be tested on different data samples and with different JSON serializers.

We invite everyone interested to test it, report issues, and join the working group if you want to do any changes.
Beste Grüße,
Alex
Meine Hobbybrauerei: http://brauerei-flaschenpost.de/ (gerade offline)
Benutzeravatar
DerDerDasBierBraut
Posting Freak
Posting Freak
Beiträge: 7890
Registriert: Donnerstag 2. Juni 2016, 20:51
Wohnort: Neustadt-Glewe

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#2

Beitrag von DerDerDasBierBraut »

Doppelpost
Zuletzt geändert von DerDerDasBierBraut am Mittwoch 22. November 2017, 00:35, insgesamt 1-mal geändert.
"Da braut sich was zusammen ... "
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens
Benutzeravatar
DerDerDasBierBraut
Posting Freak
Posting Freak
Beiträge: 7890
Registriert: Donnerstag 2. Juni 2016, 20:51
Wohnort: Neustadt-Glewe

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#3

Beitrag von DerDerDasBierBraut »

Der universelle Standard, der alle Anwendungsfälle abdeckt? :Grübel

Bild
"Da braut sich was zusammen ... "
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens
Benutzeravatar
Tozzi
Moderator
Moderator
Beiträge: 4768
Registriert: Montag 22. Februar 2016, 23:17
Wohnort: Fasano (BR) - Puglia - IT

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#4

Beitrag von Tozzi »

Wobei das ja nun wirklich in diesem Anwendungsbereich kein Hexenwerk sein müsste.
Ein Bierrezept abzubilden ist ja nun wirklich keine Zauberei.
Aber irgendwie kriegt's trotzdem keiner hin.

Beersmith Import in die GF App funktioniert, aber für den BM darf man immer noch alles nochmal eintippen, dabei geht's insgesamt um nicht mehr als höchstens 20 Variablen die irgendwie kommuniziert werden müssten.
Und so Sachen wie WP Hopfung, VWH, braucht alles Workarounds und führt generell zu falschen Berechnungen. Klappt nirgends so richtig.
Kann eigentlich nicht sein, ist aber so. :Ahh
Man möchte fast meinen, da hätte T-Systems die Finger mit drin. Dabei sind die diesmal wohl unschuldig. :Angel
Komm, Jens, lass uns da mal gemeinsam was G'scheit's basteln. :Drink
Ist dann Standard Nummer 16. Wurscht.
Viele Grüße aus Fasano
Stephan
Benutzeravatar
Berliner
Posting Freak
Posting Freak
Beiträge: 8566
Registriert: Freitag 7. April 2006, 18:02

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#5

Beitrag von Berliner »

BeerXML 1 wird ja von mehreren Applikationen unterstützt (u.a. auch von Müggelland ;-). Dass Version 2 nie wirlich angenommen wurde, liegt m.M. vor allem an der unnötigen Verkomplizierung durch den in meinen Augen viel zu akademischen Ansatz. Die Diskussion um BeerXML 2 hört sich für mich wie Selbstbefriedigung von bierbrauenden IT-Doktoranden an. Wenn BeerJSON darauf aufbaut, prophezeihe ich ihm, dass das Interesse daran auch sehr begrenzt sein wird.
Gruß vom Berliner
Benutzeravatar
PabloNop
Posting Freak
Posting Freak
Beiträge: 1206
Registriert: Sonntag 28. Juli 2013, 11:39
Wohnort: Saarbrücken

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#6

Beitrag von PabloNop »

Tozzi hat geschrieben: Mittwoch 22. November 2017, 02:18 Ein Bierrezept abzubilden ist ja nun wirklich keine Zauberei.
Aber irgendwie kriegt's trotzdem keiner hin.
Das ist halt das Zeichen dafür, daß es eben doch komplex ist.

Das Problem ist, dass die Abbildung möglichst viele Rezepte erfassen muß, es aber immer Ausnahmerezepte gibt, die eine bisher nicht bedachte Besonderheit haben. Am Ende ist entweder der Standard sehr komplex/verbastelt oder er kann nicht alle Rezepte abbilden. Auf MMuM gibt es z.B. auch viele Rezepte, die wichtige Infos noch unten im Freitext erwähnen.
Benutzeravatar
Tozzi
Moderator
Moderator
Beiträge: 4768
Registriert: Montag 22. Februar 2016, 23:17
Wohnort: Fasano (BR) - Puglia - IT

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#7

Beitrag von Tozzi »

Stimmt natürlich.

Man stellt sich das leichter vor als es ist.
Aber ist halt schon ärgerlich, dass nicht mal BeerXML wirklich überall kompatibel ist.
Viele Grüße aus Fasano
Stephan
Benutzeravatar
Berliner
Posting Freak
Posting Freak
Beiträge: 8566
Registriert: Freitag 7. April 2006, 18:02

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#8

Beitrag von Berliner »

Die Probleme fangen bei unterschiedlichen Einheiten an und hören bei nicht komplett definierten Zutaten nicht auf. Wenn man das alles standardkonform notieren will, kommt es zu solchen Monstern wie BeerXML 2.
Gruß vom Berliner
Benutzeravatar
BierBauer
Posting Freak
Posting Freak
Beiträge: 2058
Registriert: Sonntag 8. Januar 2006, 11:03
Wohnort: Erlangen

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#9

Beitrag von BierBauer »

Quasi Bier in UTC...
Viele Grüße,
Stefan
Benutzeravatar
universam
Posting Freak
Posting Freak
Beiträge: 518
Registriert: Dienstag 20. September 2016, 16:43
Wohnort: Selters
Kontaktdaten:

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#10

Beitrag von universam »

Ganz ehrlich, das hat endlich mal Substanz!
Unit Tests, git workflow, dynamisch ausgelegt und dokumentiert.

Da versteht jemand was von seinem Job wie ich finde. Da es ein Superset ist wird es ja auch kein Problem sein Konverter dahin zu coden.
Bin gespannt...
iSpindel - die DIY elektronische Spindel
Brauhelferlein - die mini Brausteuerung
Benutzeravatar
olibaer
Posting Freak
Posting Freak
Beiträge: 2827
Registriert: Dienstag 6. April 2004, 00:49
Kontaktdaten:

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#11

Beitrag von olibaer »

Hallo zusammen,
Berliner hat geschrieben: Mittwoch 22. November 2017, 19:27 Die Probleme fangen bei unterschiedlichen Einheiten an und hören bei nicht komplett definierten Zutaten nicht auf. Wenn man das alles standardkonform notieren will, kommt es zu solchen Monstern wie BeerXML 2.
Sehe ich auch so - ein Fass ohne Boden.

Letzten Endes ist es aber auch ein hausgemachtes Problem, da der "(Hobby)brauer" eine "Rezeptur", angelernt, als einen bunten Mix aus Prozessdaten, Prozessschritten und Einsatzmengen begreift - im Datenaustausch ein Fiasko - selbst ohne konsolidierte Umrechnungsmodalitäten und angehängten Sprachgebrauch.

Konzeptionell ist "Rezeptur" nur eine versionierte und vom Brauer benannte Wortschöpfung mit Gültigkeitszeitraum(Hülle), in die vorgefertigte Strukturelemente wie "Prozessdaten", "Prozessschritte" und "Einsatzmenge je Herstellmenge(-> Stückliste)" nach belieben eingehängt oder wieder entfernt werden.

On Top:
Jeder möchte seine Einzel- und Sonderfälle in einer Schnittstelle abgebildet sehen. Wenn man sich nur im Ansatz darauf einlässt, geht das für keinen gut aus.
Gruss
Oli
_____________________________
https://brewrecipedeveloper.de

Brauwasser - bitte hier entlang
Gärschwierigkeiten - bitte hier entlang
Grundlagen Karbonisierung - bitte hier entlang
Rezeptberatung anfragen - bitte hier entlang
Benutzeravatar
olibaer
Posting Freak
Posting Freak
Beiträge: 2827
Registriert: Dienstag 6. April 2004, 00:49
Kontaktdaten:

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#12

Beitrag von olibaer »

Hallo universam,
universam hat geschrieben: Mittwoch 22. November 2017, 21:22 Ganz ehrlich, das hat endlich mal Substanz!
Unit Tests, git workflow, dynamisch ausgelegt und dokumentiert. Da versteht jemand was von seinem Job wie ich finde. Da es ein Superset ist wird es ja auch kein Problem sein Konverter dahin zu coden. Bin gespannt...
Liest sich gut - ein Crack vor laufender Kamera.

Bis wann sagtest du hast du das angefragte Schnittstellenproblem gelöst ?
Egal, mach dir die Knie blutig und schick' den downloadlink - schick wäre vorm' Jahreswechsel .
Gruss
Oli
_____________________________
https://brewrecipedeveloper.de

Brauwasser - bitte hier entlang
Gärschwierigkeiten - bitte hier entlang
Grundlagen Karbonisierung - bitte hier entlang
Rezeptberatung anfragen - bitte hier entlang
Benutzeravatar
Tozzi
Moderator
Moderator
Beiträge: 4768
Registriert: Montag 22. Februar 2016, 23:17
Wohnort: Fasano (BR) - Puglia - IT

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#13

Beitrag von Tozzi »

Die Frage ist halt auch immer wieder, wieviel davon muss man eigentlich abbilden und warum.
Will ich den Maischprozess abbilden und damit z.B. einen BM ansteuern?
Oder soll die Gärführung auch mit rein?
Wenn man das alles unter einen Hut bringen will, am besten noch durchnormalisiert, dann wird's uferlos, klar.
Aber vielleicht will man dann an irgendeinem Punkt eine auf Fuzzy Logic basierte Regelbasis doch eher auslagern.
Viele Grüße aus Fasano
Stephan
Benutzeravatar
Alt-Phex
Moderator
Moderator
Beiträge: 9882
Registriert: Mittwoch 1. Februar 2012, 01:05
Wohnort: Düsseldorf

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#14

Beitrag von Alt-Phex »

Man muss Rezepte doch sowieso immer auf seine eigene Anlage anpassen. Was soll das also ?
>>Impfung rettet Leben und Kultur!<<

"Viele Biere werden am Etikettierer gemacht"
Benutzeravatar
universam
Posting Freak
Posting Freak
Beiträge: 518
Registriert: Dienstag 20. September 2016, 16:43
Wohnort: Selters
Kontaktdaten:

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#15

Beitrag von universam »

olibaer hat geschrieben: Mittwoch 22. November 2017, 23:49 Bis wann sagtest du hast du das angefragte Schnittstellenproblem gelöst ?
Naja, ich habe ja nur bemerkt dass es technisch schön umgesetzt ist - zu euren anderen Einwänden kann ich sonst nichts sinnvolles hinzufügen :Wink
Für meine Brausoftware (Konsument) ist dieses Konzept sehr schön zu parsen, vorallem gefällt mir die Flexibilität nur das zu verwenden was ich auch wirklich verwenden kann. Was mir allerdings nicht gefällt ist dass man die Einheiten frei lässt, daher muss man Konverter in jede Freiheit basteln, und das ist nun wieder das Gegenteil von Standard.

Ob das von den Produzenten (KbH, MMum) nun adaptiert wird, wage ich nicht abzuschätzen. Deshalb "bin ich gespannt".
Und ja, das bezweifle ich nicht, davon lebt und stirbt ein Standard ...
iSpindel - die DIY elektronische Spindel
Brauhelferlein - die mini Brausteuerung
Benutzeravatar
katzlbt
Posting Senior
Posting Senior
Beiträge: 315
Registriert: Montag 21. März 2016, 20:14
Wohnort: Innsbruck

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#16

Beitrag von katzlbt »

Ich hab mir das beerjson-git angeschaut, weil mein Braurechner nativ ja auch mit JSON (als Speicherformat) arbeitet.
Das erste was man sieht sind separate Schemadefinitionen von Hopfen, Malz, Wasser, usw.
Das führt doch zu nix, das ist ja 1:1 die Komplexität von XML auf JSON umgelegt, oder?

Das überzeugt mich nicht. Ein Anwärter auf "Standard", der muss simpel und verständlich sein.
Ein beer-rezept.json und mit gutem Beispiel (Schemadiagramm, Mind-Map oder Kommentare) und gut isses.
Es ist zwar schön wenn ich einen Hopfen von Rezept X nach Rezept Y als File exportieren kann, aber bei den paar Zahlen bin ich schneller mit neu eintippen. Als Teil eines Rezeptes erhält der Hopfen z.B. neue Parameter: Gewicht, Zugabezeitpunkt, IBU (berechnet), die ohne Rezept undefiniert sind, auch keinen Sinn machen. Yeast ist wieder überdefiniert: Name, Type, Form, Laboratory, Product_ID ... aber im Rezept wird sie angestellt, was neue Parameter erzeugt. Ein String/Notiz reicht eigentlich für mich.

Aber das gute am JSON ist ja, dass es ohne Schema funktioniert, also, dass jedes Programm eigene Parameter in Hash-Maps/dicts reinpacken kann ohne _große_ Kollisionsgefahr.

Das wichtigste für mich wäre aber die Maßeinheiten (metrisch) zu definieren.

LG,
Thomas.

Hier mein BEER-JSON Format nein, besser mein Standard :Bigsmile ...

Code: Alles auswählen

{
	"name": "Maibock Sticke",
	"creator": "Cat",
	"malt": [{
		"kind": "Wiener",
		"pct": 50,
		"ebc": 9,
		"kg": 7
	}, {
		"kind": "Pils",
		"pct": 39.3,
		"kg": 5.5,
		"ebc": 5
	}, {
		"kind": "Cara Pils",
		"pct": 4.3,
		"kg": 0.6,
		"ebc": 8
	}, {
		"kind": "Melanoidin",
		"pct": 4.3,
		"ebc": 20,
		"kg": 0.6
	}, {
		"kind": "Cara Hell",
		"pct": 2.1,
		"kg": 0.3,
		"ebc": 8
	}],
	"hop": [{
		"kind": "Perle",
		"alpha": 9.6,
		"tadd": 80,
		"gpl": 0.463,
		"g": 25
	}, {
		"kind": "Hallertau Mittelfrh",
		"alpha": 3.4,
		"tadd": 70,
		"gpl": 1.852,
		"g": 100
	}, {
		"kind": "Saazer",
		"alpha": 3.4,
		"time": 0,
		"gpl": 3.241,
		"g": 175,
		"tadd": 0
	}],
	"yeast": {
		"kind": "Saflager 84/70",
		"txt": "Direkt draufgeschttet."
	},
	"mash": {
		"startTemp": 38,
		"startDuration": 20,
		"rest": [
			[55, 10],
			[62, 30],
			[72, 30],
			[76, 5],
			[0, 0]
		]
	},
	"cook": {
		"duration": 70
	},
	"totalMalt": 14,
	"plato": 14.74,
	"sg": "1.060",
	"ausschlag": "54",
	"ibu": 41,
	"aaiTemp": 80,
	"aaiTime": 30,
	"ebc": 14,
	"ferment": {
		"t0": 18,
		"ta": 14
	}
}
Zuletzt geändert von katzlbt am Donnerstag 23. November 2017, 21:03, insgesamt 2-mal geändert.
Benutzeravatar
katzlbt
Posting Senior
Posting Senior
Beiträge: 315
Registriert: Montag 21. März 2016, 20:14
Wohnort: Innsbruck

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#17

Beitrag von katzlbt »

Alt-Phex hat geschrieben: Donnerstag 23. November 2017, 00:44 Man muss Rezepte doch sowieso immer auf seine eigene Anlage anpassen. Was soll das also ?
Eigentlich muss man nur die Sudwerkparameter kennen, dann kann eine Brausoftware das ganze Rezept ziemlich sofort umrechnen.
Es ist aber nicht üblich Rezepte (speziell Hopfen- und Malzmengen) unabhängig vom Ausschlag in g/l Hopfen oder % Malzanteil anzugeben.
In der Literatur wird oft ein Hektoliterrezept angegeben, das meist einfacher (im Kopf) umzurechnen geht.
Im Wiki findet man: "Dieses Rezept gilt für 20l"

:Drink
Thomas.
TheCK
Posting Senior
Posting Senior
Beiträge: 454
Registriert: Montag 30. März 2015, 11:01
Wohnort: Wien

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#18

Beitrag von TheCK »

katzlbt hat geschrieben: Donnerstag 23. November 2017, 20:35 Aber das gute am JSON ist ja, dass es ohne Schema funktioniert, also, dass jedes Programm eigene Parameter in Hash-Maps/dicts reinpacken kann ohne _große_ Kollisionsgefahr.
Naja, das ist dann aber für den Dateiaustausch ein großer Nachteil. Irgendwer muß das Ganze ja interpretieren, d.h. es muß (wie schon bei XML) einen gemeinsamen Namensraum und klar definierte/verfügbare Parameter/Segmente/Name-Value-Pairs geben.
Was - bis auf die Schreibweise - unterscheidet JSON dann vom XML?
Deshalb kann man so etwas meiner Meinung nach auch nicht für einen "Verwerter"-übergreifenden Standard nutzen wenn jeder sein eigenes Süppchen kocht.
LG Chris
Benutzeravatar
nrtn
Posting Klettermax
Posting Klettermax
Beiträge: 279
Registriert: Freitag 24. März 2017, 17:25

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#19

Beitrag von nrtn »

katzlbt hat geschrieben: Donnerstag 23. November 2017, 20:54 Eigentlich muss man nur die Sudwerkparameter kennen, dann kann eine Brausoftware das ganze Rezept ziemlich sofort umrechnen.
Geht so, ist z.B. garnicht so klar ob Haupt- und Nachgussmenge als Rezept- oder Anlagenparameter zu sehen sind...
Benutzeravatar
katzlbt
Posting Senior
Posting Senior
Beiträge: 315
Registriert: Montag 21. März 2016, 20:14
Wohnort: Innsbruck

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#20

Beitrag von katzlbt »

nrtn hat geschrieben: Donnerstag 23. November 2017, 21:41
katzlbt hat geschrieben: Donnerstag 23. November 2017, 20:54 Eigentlich muss man nur die Sudwerkparameter kennen, dann kann eine Brausoftware das ganze Rezept ziemlich sofort umrechnen.
Geht so, ist z.B. garnicht so klar ob Haupt- und Nachgussmenge als Rezept- oder Anlagenparameter zu sehen sind...
Liter Soll-Ausschlag, durchschnittliche Sudwerkausbeute und maximale Malzmenge sind Sudwerkparameter mit denen man die Schüttung berechnen kann. Im Rezept kommt dann der Ist-Ausschlag und Dichte als Messung, von der man die Ist-Sudhausausbeute berechnet.
Die Dichte der Würze sollte man je nach Rezept messtechnisch durch Verdunstung oder Verdünnen einstellen, da muss man seine Anlage kennen.
Haupt- und Nachgussmenge sind Messungen, wobei ich den Nachguss/das Läuterwasser nie messe (Ich brauche was nötig ist, bis nicht mehr süß, sonst reduziere ich ja meine Ausbeute). Bei Starkbieren muss man natürlich die Wassermenge reduzieren oder die Verdunstung erhöhen.

Also manche Parameter sind ganz einfach als Soll- und Ist-Wert doppelt vorhanden. Ein Sudwerk muss auch für ein Starkbier anders parametrisiert werden.

LG,
Thomas
Benutzeravatar
katzlbt
Posting Senior
Posting Senior
Beiträge: 315
Registriert: Montag 21. März 2016, 20:14
Wohnort: Innsbruck

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#21

Beitrag von katzlbt »

TheCK hat geschrieben: Donnerstag 23. November 2017, 20:55 Naja, das ist dann aber für den Dateiaustausch ein großer Nachteil. Irgendwer muß das Ganze ja interpretieren, d.h. es muß (wie schon bei XML) einen gemeinsamen Namensraum und klar definierte/verfügbare Parameter/Segmente/Name-Value-Pairs geben.
Was - bis auf die Schreibweise - unterscheidet JSON dann vom XML?
Deshalb kann man so etwas meiner Meinung nach auch nicht für einen "Verwerter"-übergreifenden Standard nutzen wenn jeder sein eigenes Süppchen kocht.
In der IT is es oft leichter das Rad neu zu erfinden, weil man die Reibungsverluste durch endlose Diskussionen vermeidet. :Wink
JSON besteht nur aus Dictionaries/Hashes/Objects (unsortiert), Arrays und Daten.
XML kennt keine Dictionaries und Arrays, sondern Attribute und Elements, was Probleme aufwirft und auch nicht gut zu JSON (oder jede andere Datenstruktur) übersetzbar ist.
XML wirft leider mehr Probleme auf als es löst.

Ein Standard wäre der kleinste gemeinsame JSON File um ein Rezept aufzuschreiben.
Jeder "Verwerter" nimmt was er versteht und stellt das Rezept dar, kann aber zusätzliche Parameter mitspeichern.
So könnte man ein Rezept in eine Wasserrechner stecken und das Wasser genau parametrisieren, obwohl das der Rezeptrechner noch nicht kann.
newnoise
Posting Klettermax
Posting Klettermax
Beiträge: 248
Registriert: Mittwoch 30. März 2016, 18:57

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#22

Beitrag von newnoise »

katzlbt hat geschrieben: Donnerstag 23. November 2017, 20:35 Das erste was man sieht sind separate Schemadefinitionen von Hopfen, Malz, Wasser, usw.
Das führt doch zu nix, das ist ja 1:1 die Komplexität von XML auf JSON umgelegt, oder?
Man kann in JSON-Schema-Definitionen die Datei aufteilen, das hat Vorteile, weil es übersichtlicher ist und so Objekte einfach wiederverwendet werden können. Beispielsweise könnte man ein Objekt "Menge" definieren, welches den Wert als Zahl und die Maßeinheit enthält. Damit können dann absolute Angaben (Liter, Gramm) oder relative Angaben abgebildet werden. Dieses Objekt kann man dann beispielweise bei Malz, Hopfen etc. einbinden.

ABER das heißt nicht, dass man dann auch das Rezept in 10 Files speichern muss! Am Ende kommt trotzdem eine JSON-File mit dem Rezept raus.

Insbesondere, dass das Rezept hinterher für Menschen leserlich bleibt (bzw. bleiben sollte, wenn es nicht zu kompliziert gemacht wird) ist für mich der riesige Vorteil ggü. XML, was doch sehr schnell chaotisch anmutet. Nichtsdestotrotz bringt ein Standard nichts, der nicht genutzt wird, insofern sollten die Macher rechtzeitig bei den Herstellern von Brausoft- und Hardware klären ob es da Intentionen gibt, dass zu implementieren. Sonst kann man sich den Aufwand sparen.
Benutzeravatar
katzlbt
Posting Senior
Posting Senior
Beiträge: 315
Registriert: Montag 21. März 2016, 20:14
Wohnort: Innsbruck

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#23

Beitrag von katzlbt »

newnoise hat geschrieben: Freitag 24. November 2017, 06:57
katzlbt hat geschrieben: Donnerstag 23. November 2017, 20:35 Das erste was man sieht sind separate Schemadefinitionen von Hopfen, Malz, Wasser, usw.
Das führt doch zu nix, das ist ja 1:1 die Komplexität von XML auf JSON umgelegt, oder?
Man kann in JSON-Schema-Definitionen die Datei aufteilen, das hat Vorteile, weil es übersichtlicher ist und so Objekte einfach wiederverwendet werden können. Beispielsweise könnte man ein Objekt "Menge" definieren, welches den Wert als Zahl und die Maßeinheit enthält. Damit können dann absolute Angaben (Liter, Gramm) oder relative Angaben abgebildet werden. Dieses Objekt kann man dann beispielweise bei Malz, Hopfen etc. einbinden.

ABER das heißt nicht, dass man dann auch das Rezept in 10 Files speichern muss! Am Ende kommt trotzdem eine JSON-File mit dem Rezept raus.

Insbesondere, dass das Rezept hinterher für Menschen leserlich bleibt (bzw. bleiben sollte, wenn es nicht zu kompliziert gemacht wird) ist für mich der riesige Vorteil ggü. XML, was doch sehr schnell chaotisch anmutet. Nichtsdestotrotz bringt ein Standard nichts, der nicht genutzt wird, insofern sollten die Macher rechtzeitig bei den Herstellern von Brausoft- und Hardware klären ob es da Intentionen gibt, dass zu implementieren. Sonst kann man sich den Aufwand sparen.
Wenn man Übersichtlichkeit wollte, dann sollte man eine MindMap nehmen, z.B. FreeMind, weniger übersichtlich wäre eine Definition als Backus Naur Form, hätte man aber vermutlich auf 1 Seite platz (siehe json.org). Auch als Datenbankschema könnte man es definieren (dann wäre man wenigstens sicher, dass man das als DB speichern kann). Schema Definitionen sind dazu da, um z.B. Rezept Files (XML oder JSON) auf Konformität zu verifizieren und sonst gar nix. Interessanterweise hat da Originaldokument des Beer-XML Grafiken, bei denen man aber gleich sieht, wie "bloated" das ganze wird.

Hier kann man sich den (sorry) Wahnsinn anschauen:
https://github.com/beerjson/beerjson/tr ... tests/real
Da waren keine Profis am Werk!
Schon allein wie man die Maßeinheiten definiert, führt dazu, dass eine Software die sowas importieren wollte grausliche Umrechnungsprobleme hat: "scale": "L"(Lovibond), value: 13; "density": "sg", "value": 1.044
Brix gibt es ganz einfach nicht, dafür viele Volumeneinheiten bis zum UK Barrel!
Das wichtigste an einem Austauschformat (Datemmodell) wäre eine STANDARD MASSEINHEIT für z.B. Volumen zu verwenden. Dann könnte die Anzeigesoftware (View) das in Cups oder Pints umrechnen.

Um so einen Standard zu importieren brauche ich mehr Zeit als einen gesamten Braurechner zu schreiben.
User: "Ich hab da ein Rezept mit 3 cup Zucker. Warum geht das nicht?"

Da hilft nur eines: Nochmal neu anfangen! Das ist aber nur meine bescheidene Meinung.
Ich implemetiere es sicher nicht, weil zu kompliziert und zeitaufwändig!

LG,
Thomas.

mL (SI milliliter)
L (SI Liter)
tsp (US teaspoon)
tbsp (US tablespoon)
ozfl (US fluid ounce)
cup (US Cup)
pt (US Pint)
qt (US Quart)
gal (US Gallon)
bbl (US Barrel)
iozfl (UK fluid ounce)
ipt (UK Pint)
iqt (UK Quart)
igal (UK Gallon)
ibbl (UK Barrel)
Benutzeravatar
nrtn
Posting Klettermax
Posting Klettermax
Beiträge: 279
Registriert: Freitag 24. März 2017, 17:25

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#24

Beitrag von nrtn »

katzlbt hat geschrieben: Donnerstag 23. November 2017, 22:42 Haupt- und Nachgussmenge sind Messungen
Hm... so würde ich das auch unterschreiben...
newnoise
Posting Klettermax
Posting Klettermax
Beiträge: 248
Registriert: Mittwoch 30. März 2016, 18:57

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#25

Beitrag von newnoise »

katzlbt hat geschrieben: Freitag 24. November 2017, 10:52 Wenn man Übersichtlichkeit wollte, dann sollte man eine MindMap nehmen, z.B. FreeMind, weniger übersichtlich wäre eine Definition als Backus Naur Form, hätte man aber vermutlich auf 1 Seite platz (siehe json.org). Auch als Datenbankschema könnte man es definieren (dann wäre man wenigstens sicher, dass man das als DB speichern kann). Schema Definitionen sind dazu da, um z.B. Rezept Files (XML oder JSON) auf Konformität zu verifizieren und sonst gar nix. Interessanterweise hat da Originaldokument des Beer-XML Grafiken, bei denen man aber gleich sieht, wie "bloated" das ganze wird.
Ich will da gar gar kein großes Faß aufmachen, aber die Schemadefinitionen müssen ja nun mal entwickelt werden um Daten dagegen zu validieren. Da hilft es natürlich für die Entwickler wenn das übersichtlich in Files aufgeteilt ist. Was man mit der Definition dann macht, wie man sie für User präsentiert steht natürlich auf einem völlig anderen Blatt geschrieben. Dafür gibt es z.T. schöne Tools, wie bspw: http://jlblcc.github.io/json-schema-viewer/ oder auch der schon im Projekt eingesetzt json-schema zu markdown Konverter um leserliche Docs zu erhalten.

Von welcher Seite man das ganze aufzieht (schön dargestelltes Schema zu Schemadefinition, oder Schemadefinition zu schöner Darstellung) ist sicherlich eine Frage des Geschmacks, der Erfahrung in der Definition solcher Schemata und der Komplexität der Daten.
Benutzeravatar
Morena von Nürnberg
Posting Freak
Posting Freak
Beiträge: 517
Registriert: Mittwoch 5. November 2014, 15:42
Wohnort: Jacuma/Conde Nordbrasilien

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#26

Beitrag von Morena von Nürnberg »

katzlbt hat geschrieben: Donnerstag 23. November 2017, 23:03
In der IT is es oft leichter das Rad neu zu erfinden, weil man die Reibungsverluste durch endlose Diskussionen vermeidet. :Wink
JSON besteht nur aus Dictionaries/Hashes/Objects (unsortiert), Arrays und Daten.
XML kennt keine Dictionaries und Arrays, sondern Attribute und Elements, was Probleme aufwirft und auch nicht gut zu JSON (oder jede andere Datenstruktur) übersetzbar ist.
XML wirft leider mehr Probleme auf als es löst.

Ein Standard wäre der kleinste gemeinsame JSON File um ein Rezept aufzuschreiben.
Jeder "Verwerter" nimmt was er versteht und stellt das Rezept dar, kann aber zusätzliche Parameter mitspeichern.
So könnte man ein Rezept in eine Wasserrechner stecken und das Wasser genau parametrisieren, obwohl das der Rezeptrechner noch nicht kann.
Interessant..erfährt meine volle Zustimmung.
Wo ist das Beifallsmiley?
Benutzeravatar
katzlbt
Posting Senior
Posting Senior
Beiträge: 315
Registriert: Montag 21. März 2016, 20:14
Wohnort: Innsbruck

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#27

Beitrag von katzlbt »

newnoise hat geschrieben: Samstag 25. November 2017, 08:15 Ich will da gar gar kein großes Faß aufmachen, aber die Schemadefinitionen müssen ja nun mal entwickelt werden um Daten dagegen zu validieren. Da hilft es natürlich für die Entwickler wenn das übersichtlich in Files aufgeteilt ist. Was man mit der Definition dann macht, wie man sie für User präsentiert steht natürlich auf einem völlig anderen Blatt geschrieben. Dafür gibt es z.T. schöne Tools, wie bspw: http://jlblcc.github.io/json-schema-viewer/ oder auch der schon im Projekt eingesetzt json-schema zu markdown Konverter um leserliche Docs zu erhalten.

Von welcher Seite man das ganze aufzieht (schön dargestelltes Schema zu Schemadefinition, oder Schemadefinition zu schöner Darstellung) ist sicherlich eine Frage des Geschmacks, der Erfahrung in der Definition solcher Schemata und der Komplexität der Daten.
Also angenommen ich schreibe ein Programm um Daten vom Bier-JSON zu importieren. Da brauche ich ein möglichst vollkommenes Beispiel-JSON, aber kein Schema zum Validieren. Mir fällt nicht einmal ein Anwendungsfall ein, der zwingend den Einsatz einer Schemavalidierung erfordert. Vielleicht kennt wer einen? Der Schaden hält sich in Grenzen wenn ein Parameter eines Hopfens fehlt, oder "ca. 1kg" statt einer Zahl kommt, oder -1 EBC angegeben wird. Das muss die Software sowieso abfangen. Vielleicht hilft sowas bei elektronischen Steuererklärungen, die von 100 verschiedenen Programmen an die Behörde übermittelt werden.

Grady Booch: "A fool with a tool is still a fool." :Wink (Nicht böse gemeint, aber früher ich hätte nie gedacht, wie oft das zutrifft.)

LG,
Thomas.
newnoise
Posting Klettermax
Posting Klettermax
Beiträge: 248
Registriert: Mittwoch 30. März 2016, 18:57

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#28

Beitrag von newnoise »

katzlbt hat geschrieben: Montag 27. November 2017, 12:06 Also angenommen ich schreibe ein Programm um Daten vom Bier-JSON zu importieren. Da brauche ich ein möglichst vollkommenes Beispiel-JSON, aber kein Schema zum Validieren. Mir fällt nicht einmal ein Anwendungsfall ein, der zwingend den Einsatz einer Schemavalidierung erfordert. Vielleicht kennt wer einen? Der Schaden hält sich in Grenzen wenn ein Parameter eines Hopfens fehlt, oder "ca. 1kg" statt einer Zahl kommt, oder -1 EBC angegeben wird. Das muss die Software sowieso abfangen. Vielleicht hilft sowas bei elektronischen Steuererklärungen, die von 100 verschiedenen Programmen an die Behörde übermittelt werden.
Deine Annahme in dem Fall ist leider aber nicht richtig. Wenn Du gegen ein korrekt und vollständig ausgearbeitetes JSON-Schema validierst musst Du eben in der Software Fehler wie "ca. 1kg" oder einen negativen EBC Wert nicht mehr behandeln. Genau für diesen Zweck erstellst Du ja das Schema!
Der JSON-Validator erkennt in diesem Fall den Fehler und reportet ihn. Wie Du den Fehler dann behandelst ist dann wieder Dir überlassen, ob Du dann versuchst den Wert trotzdem zu parsen, den User zur Korrektur aufforderst oder Math.random() anschmeißt ... Deine freie Entscheidung.
Benutzeravatar
PabloNop
Posting Freak
Posting Freak
Beiträge: 1206
Registriert: Sonntag 28. Juli 2013, 11:39
Wohnort: Saarbrücken

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#29

Beitrag von PabloNop »

katzlbt hat geschrieben: Montag 27. November 2017, 12:06 Mir fällt nicht einmal ein Anwendungsfall ein, der zwingend den Einsatz einer Schemavalidierung erfordert. Vielleicht kennt wer einen?
Was ist daran so schwer? Das Schema definiert (hoffentlich eindeutig), wie die Datei auszusehen hat. Punkt. Wenn Du eine Datei aus deiner Software exportierst, die nicht dem Schema entspricht, ist deine Software fehlerhaft. Wenn deine Software fremde Dateien einliest, kann sie validieren und ggf. wegen Inkompatibilität ablehnen.
Benutzeravatar
katzlbt
Posting Senior
Posting Senior
Beiträge: 315
Registriert: Montag 21. März 2016, 20:14
Wohnort: Innsbruck

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#30

Beitrag von katzlbt »

Das geht alles an der Kernfrage vorbei:

Wollen wir ein brauchbares BeerJson entwickeln? (*)

* das ein in einem Model-View-Controller darstellbares Modell ist
* das im Gegensatz zum BeerXML nicht Daten der View (wie z.B. Einheiten cup, barrel, grain) abbildet
* schlank und einfach ist und nur das wesentliche abbildet
* ein Rezept reproduzierbar speichern kann
* Parameter die nur Menschen verstehen als Text speichert

Dieses kann dann irgendwann, so es dann korrekt und brauchbar spezifiziert ist, ein Fan von Schemas, dem langweilig ist, als JSON-Schema ausformulieren, auf dass es an Populatität gewinnen möge. :Wink

Hier ein Link zum BeerXML: http://users.speakeasy.net/~antonw/beer ... _v2_01.pdf

Hier einmal ein Problem mit dem Übersetzen des BEER-XML:
BEER-XML: <color scale="L">3.2</color>
BEER-XML-JSON: "color": { "scale": "L", "value": 1.8 }
BEER-JSON (z.B. als Möglichkeit): { beer: { color: { L:3.2, ebc:3.6, rgb:[1,2,3] } }
Wobei lustigerweise hier die genaueste Beschreibung der Bierfarbe "rgb" ist, was alle Standardisierungskomitees völlig übersehen haben.

https://github.com/search?utf8=%E2%9C%9 ... json&type=
TheCK
Posting Senior
Posting Senior
Beiträge: 454
Registriert: Montag 30. März 2015, 11:01
Wohnort: Wien

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#31

Beitrag von TheCK »

katzlbt hat geschrieben: Mittwoch 29. November 2017, 13:24 Das geht alles an der Kernfrage vorbei:

Wollen wir ein brauchbares BeerJson entwickeln? (*)
Was aber zur Frage führt: Warum kann man BeerXML nicht entsprechend adaptieren und brauchbarer gestalten?
Oder anders formuliert: Warum will man einen neuen "Standard" schaffen, welcher parallel zum existierenden Modell aufgebaut werden soll?

Anhand deines Farbbeispiels würde sich das in XML ja mit weiterer Verschachtelung genausogut darstellen lassen:

Code: Alles auswählen

<color>
  <lovibond>3.2</lovibond>
  <ebc>3.6</ebc>
  <rgb>1-2-3</rgb>
</color>
Hätte genauso eine statische Struktur und ist parsebar.
Aber anscheinend geht der Weg immer noch in Richtung Minimalismus, also nur zu notieren was unbedingt nötig ist.
Das ist für die einzelne Anwendung OK - sie weiß ja, was sie speichert. Als Austauschformat ist das aber der Horror weil die Empfängerseite alle denkbaren Kombinationen abdecken muß. Und hier ist die Offenheit von JSON eben der Knackpunkt - wenn nicht definiert ist was möglich ist kann nicht auf alle Eventualitäten reagiert werden.
Womit sich der Kreis wieder schließt und wir beim benötigten Schema sind.
LG Chris
Benutzeravatar
katzlbt
Posting Senior
Posting Senior
Beiträge: 315
Registriert: Montag 21. März 2016, 20:14
Wohnort: Innsbruck

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#32

Beitrag von katzlbt »

TheCK hat geschrieben: Mittwoch 29. November 2017, 13:47 Anhand deines Farbbeispiels würde sich das in XML ja mit weiterer Verschachtelung genausogut darstellen lassen:
Möglich ja, aber es wurde so nicht gemacht und XML steht ja nicht zur Diskusion.
Als Austauschformat ist das aber der Horror weil die Empfängerseite alle denkbaren Kombinationen abdecken muß.
Deine Aussage gilt aber genauso für diese Repräsentation <color scale="L">3.2</color>, die ich ja nur auf 2 Arten in JSON übersetzt habe, wobei die 2. Vorteile hat, wenn man eine Variante als required und andere als optional einführt. Aber die Bierfarbe ist da doch ein ekelhafter Spezialfall.

Deine Aussage gilt auch für diese Repräsentation <amount unit="g">3200</amount> welche ich für ein Austauschformat für falsch spezifiziert halte.
{ kg:3.2 } wäre besser (und braucht keine Erklärung), aber { weight:3.2 } (weight unit is kg), und noch schlimmer ist dass das "Austauschformat" amount (Menge) parametrisiert, die man ja as Volumen, Gewicht, Scheffel, Säcke, Würfel, Stück etc. ausdrücken kann.
TheCK
Posting Senior
Posting Senior
Beiträge: 454
Registriert: Montag 30. März 2015, 11:01
Wohnort: Wien

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#33

Beitrag von TheCK »

katzlbt hat geschrieben: Mittwoch 29. November 2017, 14:12 Deine Aussage gilt auch für diese Repräsentation <amount unit="g">3200</amount> welche ich für ein Austauschformat für falsch spezifiziert halte.
{ kg:3.2 } wäre besser (und braucht keine Erklärung), aber { weight:3.2 } (weight unit is kg), und noch schlimmer ist dass das "Austauschformat" amount (Menge) parametrisiert, die man ja as Volumen, Gewicht, Scheffel, etc. ausdrücken kann.
Richtig, sämtliche parametrisierbare Tags/Objekte/Attribute sind nicht zielführend.
In einem Austauschformat muß es klar definierte Attribute geben für welche dann Werte gespeichert werden.
Somit wäre das Gewichtsbeispiel in JSON auch nur über

Code: Alles auswählen

{weight: {kg: 3.2, oz: 112.88}}
sinnvoll. Wobei man darüber diskutieren könnte ob die (endliche) Menge an zulässigen Einheit-Wert-Paaren für "weight" optional ist oder immer alle Einheiten vorhanden sein müssen.
Damit ist aber die Offenheit eben wieder dahin weil alle möglichen Ausprägungen hier vordefiniert sein müssen.
LG Chris
Benutzeravatar
katzlbt
Posting Senior
Posting Senior
Beiträge: 315
Registriert: Montag 21. März 2016, 20:14
Wohnort: Innsbruck

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#34

Beitrag von katzlbt »

TheCK hat geschrieben: Mittwoch 29. November 2017, 14:18

Code: Alles auswählen

{weight: {kg: 3.2, oz: 112.88}}
sinnvoll. Wobei man darüber diskutieren könnte ob die (endliche) Menge an zulässigen Einheit-Wert-Paaren für "weight" optional ist oder immer alle Einheiten vorhanden sein müssen.
Damit ist aber die Offenheit eben wieder dahin weil alle möglichen Ausprägungen hier vordefiniert sein müssen.
Das ist eindeutig nicht sinvoll. Ein Modell eines MVCs kennt nur eine Einheit - wenn möglich (und gerade bei der Bierfarbe geht das mangels Umrechnungsformel ev. nicht). Den Rest (also oz, lb, cups) muss die View des MVCs, also die Software beisteuern.

Ein Malz habe ich so definiert:

Code: Alles auswählen

"malt": [{
	"kind": "Wiener",
	"pct": 50,
	"ebc": 9,
	"kg": 7
	},...]
Ob man kg oder weight nimmt, ist Geschmackssache, kg ist kürzer und selbsterklärend. kg und pct (% Anteil) sind nur innerhalb des Rezeptes sinvoll.
Benutzeravatar
olibaer
Posting Freak
Posting Freak
Beiträge: 2827
Registriert: Dienstag 6. April 2004, 00:49
Kontaktdaten:

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#35

Beitrag von olibaer »

katzlbt hat geschrieben: Donnerstag 30. November 2017, 12:09 Ein Malz habe ich so definiert:

Code: Alles auswählen

"malt": [{
	"kind": "Wiener",
	"pct": 50,
	"ebc": 9,
	"kg": 7
	},...]
Und wenn in meiner Software "Wiener" mit "WienerMalz" benannt ist und ich über "WienerMalz" meine Bestände/Rezepte führe ?
Was soll dann die Importlogik mit "Wiener" anfangen ?

Was ist wenn ich zwei "WienerMalz", die in der Schnittstelle mit "Wiener" oder insgesamt beliebig benannt sind, im Bestand habe und eines davon mit 10 EBC , das andere mit 13 EBC. Wie soll eine Importlogik damit umgehen ?

Ich weiss nicht. In meiner Denke mach ich mir erst Gedanken über die Inhalte und dann über die dazu passenden Formate. So wie hier dargestellt hat weder "Anwender" noch "Programmierer" eine Freude daran.
Gruss
Oli
_____________________________
https://brewrecipedeveloper.de

Brauwasser - bitte hier entlang
Gärschwierigkeiten - bitte hier entlang
Grundlagen Karbonisierung - bitte hier entlang
Rezeptberatung anfragen - bitte hier entlang
Benutzeravatar
DerDerDasBierBraut
Posting Freak
Posting Freak
Beiträge: 7890
Registriert: Donnerstag 2. Juni 2016, 20:51
Wohnort: Neustadt-Glewe

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#36

Beitrag von DerDerDasBierBraut »

Das Zuordnen und Ersetzen der Rohstoffe für die Lagerführung ist meiner Meinung nach keine Aufgabe der Schnittstelle. Klar braucht man dafür eine Lösung, aber diese muss aus der Zielanwendung kommen.
Der KBH macht es schon so. Die im (importierten) Rezept stehenden Rohstoffe stehen erstmal autark da drin. Will man etwas mit dem Rezept machen und es enthält "unzugeordnete Rohstoffe", dann fragt der KBH, mit welchem Lagerrohstoff das "Wiener" aus dem Rezept gematcht bzw. ersetzt werden soll.

Jens
(noch immer nicht überzeugt, dass die Welt wirklich ein neues Dateiformat zum Rezeptaustausch brauch)
"Da braut sich was zusammen ... "
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens
Benutzeravatar
olibaer
Posting Freak
Posting Freak
Beiträge: 2827
Registriert: Dienstag 6. April 2004, 00:49
Kontaktdaten:

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#37

Beitrag von olibaer »

DerDerDasBierBraut hat geschrieben: Freitag 1. Dezember 2017, 11:16 Das Zuordnen und Ersetzen der Rohstoffe für die Lagerführung ist meiner Meinung nach keine Aufgabe der Schnittstelle.
Das ist ganz klar eine Aufgabe der Schnittstelle - die Konsolidierung der Stammdaten und der zu transportierenden Inhalte findet vor den export/import Mechanismen statt und nicht erst dann, wenn die Daten schon im System sind - erst "Mist" importieren und dann in Eigenregie "glatt ziehen" ? Nicht wirklich.

Wenn ich als Anwender jeden importierten Datensatz erst noch "anfassen/zuordnen/umrechnen/matchen/validieren" muss, macht eine Schnittstellte doch gar keinen Sinn. Dann kann ichs gleich "abtippen" und der Programmierer auf der Empfängerseite muss nicht noch zusätzlich ein "Matchingmodul" programmieren.
Gruss
Oli
_____________________________
https://brewrecipedeveloper.de

Brauwasser - bitte hier entlang
Gärschwierigkeiten - bitte hier entlang
Grundlagen Karbonisierung - bitte hier entlang
Rezeptberatung anfragen - bitte hier entlang
Benutzeravatar
DerDerDasBierBraut
Posting Freak
Posting Freak
Beiträge: 7890
Registriert: Donnerstag 2. Juni 2016, 20:51
Wohnort: Neustadt-Glewe

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#38

Beitrag von DerDerDasBierBraut »

Bei einer spezialisierten Schnittstelle zwischen definierten Applikationen bin ich bei Dir Oli. Da würde ich auch erwarten, dass es ein automatisches ID-Matching für Rohstoffe etc. gibt. Alles andere wäre wirklich Murks. Bei einer offenen Schnittstelle zum Datenaustausch zwischen beliebigen Anwendungen kann es aufgrund fehlender "normierter IDs" keine eindeutigen Zuordnungen geben. Dort muss die Businesslogik der Applikation, bzw. der User ran.
"Da braut sich was zusammen ... "
"Oh, Bier ;-) !"
"Nein! Was Böses!"
"Alkoholfreies Bier??? ..."
-----------
Viele Grüße
Jens
Benutzeravatar
olibaer
Posting Freak
Posting Freak
Beiträge: 2827
Registriert: Dienstag 6. April 2004, 00:49
Kontaktdaten:

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#39

Beitrag von olibaer »

DerDerDasBierBraut hat geschrieben: Freitag 1. Dezember 2017, 11:57 Bei einer offenen Schnittstelle zum Datenaustausch zwischen beliebigen Anwendungen kann es aufgrund fehlender "normierter IDs" keine eindeutigen Zuordnungen geben. Dort muss die Businesslogik der Applikation, bzw. der User ran.
Das sehe ich nicht so.

Für die paar wenige Rohstoffe und Brauhilfsstoffe die wir verwenden, lass' es vielleicht 100 sein, wird sich wohl eine Lösung finden lassen.

Man benennt einen Nummerkreis nach einer festgelegten Nomenklatur, eine Bezeichnung, eine Basismengeneinheit und eine Dosagemengeneinheit .
Diese StammListe wird versioniert, man legt eine einheitliche Bezugsmenge für die Rezepte fest, z.B. 100 l Würze, und das wars. Damit ist die Schnittstelle an dieser Stelle einheitlich und die Interpretation der Übertragungsdaten übernimmt die Software. 8h Konsolidierungsgespräche mit den "Austauschwilligen Entwicklern" würde genügen.

Selbstversändlich muss man auch hier die Bezeichnungen in der eigenen Software mit den Stammdaten aus der Liste matchen(wie auch immer), aber eben nicht je (Import)Vorgang, sondern nur einmalig.

In welchem Format die Daten dann übertragen werden, verkommt dabei zur Nebensache.
Gruss
Oli
_____________________________
https://brewrecipedeveloper.de

Brauwasser - bitte hier entlang
Gärschwierigkeiten - bitte hier entlang
Grundlagen Karbonisierung - bitte hier entlang
Rezeptberatung anfragen - bitte hier entlang
Benutzeravatar
katzlbt
Posting Senior
Posting Senior
Beiträge: 315
Registriert: Montag 21. März 2016, 20:14
Wohnort: Innsbruck

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#40

Beitrag von katzlbt »

olibaer hat geschrieben: Freitag 1. Dezember 2017, 11:01 Und wenn in meiner Software "Wiener" mit "WienerMalz" benannt ist und ich über "WienerMalz" meine Bestände/Rezepte führe ?
Was soll dann die Importlogik mit "Wiener" anfangen ?

Was ist wenn ich zwei "WienerMalz", die in der Schnittstelle mit "Wiener" oder insgesamt beliebig benannt sind, im Bestand habe und eines davon mit 10 EBC , das andere mit 13 EBC. Wie soll eine Importlogik damit umgehen ?

Ich weiss nicht. In meiner Denke mach ich mir erst Gedanken über die Inhalte und dann über die dazu passenden Formate. So wie hier dargestellt hat weder "Anwender" noch "Programmierer" eine Freude daran.
Deine Sicht ist die des Anwenders, der das "Modell" nie zu Gesicht bekommen sollte.
Eine Importlogik soll so unkompliziert wie möglich zu programmieren sein, und ein gut designtes Austauschformat unterstützt das.
Ein schlechtes Austauschformat macht die Importlogik so kompliziert, dass sich ein Programmierer genervt abwendet (siehe BeerXML).
DerDerDasBierBraut hat geschrieben: Freitag 1. Dezember 2017, 11:57 Bei einer spezialisierten Schnittstelle zwischen definierten Applikationen bin ich bei Dir Oli. Da würde ich auch erwarten, dass es ein automatisches ID-Matching für Rohstoffe etc. gibt. Alles andere wäre wirklich Murks. Bei einer offenen Schnittstelle zum Datenaustausch zwischen beliebigen Anwendungen kann es aufgrund fehlender "normierter IDs" keine eindeutigen Zuordnungen geben. Dort muss die Businesslogik der Applikation, bzw. der User ran.
Da muss ich dir recht geben. Wenn es branchenweit normierte IDs (Barcodes, ISBNs, URIs etc. gibt) dann soll man die auch verwenden. Hier gibt es die aber nicht weil sonst würde ich Malz so definieren { malzId:17, kg:7 pct:66 } und Name, EBC, Hersteller, wasauchinmmer sind woanders definiert, weil jeder Beteiligte weiß was Malz#17 ist.

Gerade beim Bier gibt es das nicht. Z.B. habe ich noch nie 2 Hopfen mit demselben Namen und demselben Alphasäuregehalt bekommen.
olibaer hat geschrieben: Freitag 1. Dezember 2017, 13:42
DerDerDasBierBraut hat geschrieben: Freitag 1. Dezember 2017, 11:57 Bei einer offenen Schnittstelle zum Datenaustausch zwischen beliebigen Anwendungen kann es aufgrund fehlender "normierter IDs" keine eindeutigen Zuordnungen geben. Dort muss die Businesslogik der Applikation, bzw. der User ran.
Das sehe ich nicht so.

Für die paar wenige Rohstoffe und Brauhilfsstoffe die wir verwenden, lass' es vielleicht 100 sein, wird sich wohl eine Lösung finden lassen.

Man benennt einen Nummerkreis nach einer festgelegten Nomenklatur, eine Bezeichnung, eine Basismengeneinheit und eine Dosagemengeneinheit .
Diese StammListe wird versioniert, man legt eine einheitliche Bezugsmenge für die Rezepte fest, z.B. 100 l Würze, und das wars. Damit ist die Schnittstelle an dieser Stelle einheitlich und die Interpretation der Übertragungsdaten übernimmt die Software. 8h Konsolidierungsgespräche mit den "Austauschwilligen Entwicklern" würde genügen.

Selbstversändlich muss man auch hier die Bezeichnungen in der eigenen Software mit den Stammdaten aus der Liste matchen(wie auch immer), aber eben nicht je (Import)Vorgang, sondern nur einmalig.

In welchem Format die Daten dann übertragen werden, verkommt dabei zur Nebensache.
Tut mir leid Olibär. Da bin ich aber gar nicht deiner Meinung. Eine Definition von MalzIDs und HopfenIDs hat nicht einmal BeerXML versucht, warum wohl?

Die Bezugsmenge 1hl (Ausschlag?) ist für Printmedien gut und ein komplett anderes Thema. Ich brauche keine um ein Rezept zwischen Sudwerken automatisch umzurechnen.

Wenn man ein importiertes Rezept umsetzt, also braut, dann entsteht ein neues Rezept (Brauprotokoll) und dann muss man sowieso eine händische Substitutionsphase vornehmen, bei der Malze und Hopfen durch vorhandene Rohstoffe ersetzt werden, die so ausgesucht werden, dass das Ergebnis gleich bitter, gleich gefärbt und gleich schmeckend heraus kommt. Das ist die Aufgabe des Brauers und nicht einer Software, glaube ich.

Fast hätte ich es vergessen: natürlich würde ein BeerJSON dem Malz eine optionale url/uri als extra Parameter zur Verfügung stellen, die eine Software als Referenz zum Dateblatt des Herstellers, oder intern als DB-ID verwenden kann.
Benutzeravatar
Sura
Posting Freak
Posting Freak
Beiträge: 3489
Registriert: Montag 2. November 2015, 22:37

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#41

Beitrag von Sura »

Jetzt mal ganz ketzerisch gefragt:
Wenn ich Hopfen sowie Malze und wahrscheinlich auch Hefen..... und dann noch die ganzen anderen Zutaten wie Süßholz, Fichtennadeln von Hand matchen müsste, dazu dann noch die Temperaturen und Rasten sowieso anpassen muss, weil mein System z.b. mit 2°C/min heizt bzw. beim Bottichmaischen sozusagen springt..... was spare ich jetzt genau wenn ich ein Rezept importiere statt es einfach einzugeben? Also außer die Rasttemperaturen und die schlichte Anzahl an Malzen bzw. Hopfen?

Wenn man wirklich miteinander tauschen möchte über Programme hinweg, ist der beste Standard für den Hintern, wenn das Importprogramm nicht ein perfektes Matchingfenster zur Verfügung stellt....
Davon abgesehen habe ich mich genug mit offenen Standarts rumgeschlagen, das sich mir jedesmal mit schaudern die Nackenhaare kräuseln wenn ich mit sowas arbeiten muss. Ich habe noch keinen gesehen bei dem nicht innerhalb kürzester Zeit der Ausnahmen und Besonderheitenkatalog deutlich umfangreicher war als der des eigentlichen "Standarts" ... lieber 10 verschiedene und jeweils fest definierte einbauen als Einen mit 10 Mutationen.....
"Es ist schon alles gesagt, nur noch nicht von jedem."
(Karl Valentin)
Benutzeravatar
olibaer
Posting Freak
Posting Freak
Beiträge: 2827
Registriert: Dienstag 6. April 2004, 00:49
Kontaktdaten:

Re: Entwicklung neues Brau-Dateiformat - BeerJSON

#42

Beitrag von olibaer »

Sura hat geschrieben: Montag 4. Dezember 2017, 19:47 Jetzt mal ganz ketzerisch gefragt:
Wenn ich Hopfen sowie Malze und wahrscheinlich auch Hefen..... und dann noch die ganzen anderen Zutaten wie Süßholz, Fichtennadeln von Hand matchen müsste, dazu dann noch die Temperaturen und Rasten sowieso anpassen muss, weil mein System z.b. mit 2°C/min heizt bzw. beim Bottichmaischen sozusagen springt..... was spare ich jetzt genau wenn ich ein Rezept importiere statt es einfach einzugeben?
Das ist nicht ketzerisch gefragt - das ist die Frage rund um die Rohstoffe überhaupt und das haut in genau die Kerbe, die ich oben anspreche.

Wenn keinerlei Stammdaten konsolidiert sind, spart sich weder Entwickler noch Anwender irgend etwas.
Obendrein ein Alptraum, wenn sich "Anwender" beim matching vertut und der Import nicht klappt oder in die Hosen geht, womöglich "Krampf gebaut & gebraut wird". Wo laufen da wohl die Supportanfragen auf ? Genau ? Beim Entwickler und das in Massen.
Ich wollte das so nicht haben und kann mir das Chaos schon in allen Facetten vorstellen - braucht niemand.

In eine ganz ähnlich Kerbe haut, dass ich "Zutatenliste" von "Prozessparametern" trenne. Es geht doch bei "Zutatenliste" immer nur um "Menge pro ..." und bei "Prozessparametern" im einfachsten Fall um "ProzessparameterName, Zeitpunkt, Dauer und Temperatur."

Ich denke das ist alles nicht so tragisch und funktioniert auch schon in vielen Varianten und wenn mal klar ist, wer "Master" und wer "Slave" ist, rundet das die ganze Sache ab.
Und überhaupt: wenn jemand den Citratcyclus um sein vergorenes tanzen möchte, muss das ja nicht zwingend ein Teil der Schnittstelle sein - dafür gibts dann Bemerkungsspalten.
Gruss
Oli
_____________________________
https://brewrecipedeveloper.de

Brauwasser - bitte hier entlang
Gärschwierigkeiten - bitte hier entlang
Grundlagen Karbonisierung - bitte hier entlang
Rezeptberatung anfragen - bitte hier entlang
Antworten