You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Es ist schon erstaunlich, welcher Hype um dieses Repository entfacht wurde... Respekt fürs Medien-Manöver!
Ich bekomme graue Haare, wenn ich sehe, dass hier Studenten vom HPI am Werke sind, die den Unterschied zwischen unstrukturierten, semi-strukturierten und strukturierten Daten kennen sollten und eigentlich auch in der Lage sein sollten, erst entsprechende Strukturen (!) zu entwickeln und dann Datenformate dafür auszuwählen.
Wohin soll Euch bitte "Markdown", welches ein Schreibformat für Webmenschen ist, als Datenformat tragen?
Meiner Ansicht nach kommt ihr bei juristischen Daten nicht um XML rum. Das wurde von Charles F. Goldfarb doch gerade entwickelt, um Datenstellen in juristischen Texten zu markieren und maschinenlesbar zu sein. Semi-strukturierte Datenformate wie "Markdown" oder auch "HTML" sind nicht gut geeignet für juristische Daten, weil sie zu wenig Strukturinformation offenbaren - höchstens für eine menschenlesbare Repräsentation der Daten.
Bei strukturierten Daten gibts regelmäßig zusätzlich zu den Daten noch ein Schema-Format, um Kenntnis über die Struktur zu haben und Format-Validierungen zu ermöglichen (XML/XSD/DTD).
Es lässt sich in diesem Repository an Struktur nicht wirklich viel finden, nämlich lediglich
(a) der alphabetischen Repo-Index und
(b) einige Zeilen in jedem Gesetzes-Dateikopf (Ausfertigungsdatum, Fundstelle, Neugefasst durch, Zuletzt geändert durch), sowie
(c) einige Markdown-Tags, etwa "Doppelhash Absatz/Überschrift".
Insgesamt weniger, als auf den seit Jahren gut gepflegten Platformen http://buzer.de, http://openjur.de, http://juris.de/ oder http://gesetze-im-internet.de. Ich kann bislang keine Neuerungen oder Verbesserungen erkennen.
Zudem ist es grotesk, dass bereits bestehende und etablierte XML-Gesetzesstandards des BMJ und der Verwaltung gänzlich ignoriert werden. Ich denke, ihr wollt Euch in den bestehenden Toolchain einklinken und die Arbeit damit verbessern - dann macht das doch einfach mal! Werft mal einen Blick in die UML Spezifikation von xNorm und eNorm. Das Verfahren läuft mit diesen Werkzeugen und nicht mit Git oder auf Github :)
Wir halten fest: Die Struktur der Daten ist schwach. Es gibt keine Schemadateien. Es gibt kein Pflegemodell.
The text was updated successfully, but these errors were encountered:
Meiner Meinung nach kann es gerade nicht das Ziel sein, sich ,,in den bestehenden Toolchain einzuklinken und die Arbeit damit zu verbessern''. Dann würde man ja quasi nur eine OpenSource Alternative zu eNorm entwickeln, ohne laufende Rückmeldung der derzeitigen Nutzer, die -wenn überhaupt- viell. in 5-10 Jahren mal eingesetzt wird.
Ein Großteil der Funktionen hat für die Zivilgesellschaft auch einfach keinerlei Nutzen, wenn es z.B. um Dinge wie richtiges Format zur Veröffentlichung im Bundesgesetzblatt etc. geht.
Gibt es konkrete Beispiele, welche Strukturdaten aus der derzeitigen .xml Fassung von Gesetze-im-Internet nicht theoretisch auch in Markdown dargestellt werden können? Klar ist derzeit noch nicht alles drin. Aber ansonsten ist Markdown eben doch überlegen, weil es zur gleichen Maschinenlesbarkeit zusätzlich die Menschenlesbarkeit mitliefert.
(Ich spreche nicht fürs Projekt, nur meine eigene Meinung)
@jakoch Ich würde mal behaupten, dass mehr Leute mit git/github vertraut sind, als mit der Spezial-Lösung der Gesetzemacher. Wahrscheinlich gilt selbiges auch für Markdown. Daher hat das schon einen Vorteil. Außerdem lassen sich durch die Verwendung von Markdown an den Github-Diffs ziemlich direkt Änderungen ablesen – und zwar selbst für Git/Github-Laien und ich dachte, dass genau wäre die Idee hinter diesem Projekt.
Deinen Kommentar am Anfang hättest du dir darüber hinaus vielleicht sparen können. Ich wüsste nicht, welche konstruktive Bedeutung ich daraus ablesen können soll. Wenn dir etwas nicht gefällt, dann mache doch einen Github-Fork! kleiner Scherz am Rande/Ende
Es ist schon erstaunlich, welcher Hype um dieses Repository entfacht wurde... Respekt fürs Medien-Manöver!
Ich bekomme graue Haare, wenn ich sehe, dass hier Studenten vom HPI am Werke sind, die den Unterschied zwischen unstrukturierten, semi-strukturierten und strukturierten Daten kennen sollten und eigentlich auch in der Lage sein sollten, erst entsprechende Strukturen (!) zu entwickeln und dann Datenformate dafür auszuwählen.
Wohin soll Euch bitte "Markdown", welches ein Schreibformat für Webmenschen ist, als Datenformat tragen?
Meiner Ansicht nach kommt ihr bei juristischen Daten nicht um XML rum. Das wurde von Charles F. Goldfarb doch gerade entwickelt, um Datenstellen in juristischen Texten zu markieren und maschinenlesbar zu sein. Semi-strukturierte Datenformate wie "Markdown" oder auch "HTML" sind nicht gut geeignet für juristische Daten, weil sie zu wenig Strukturinformation offenbaren - höchstens für eine menschenlesbare Repräsentation der Daten.
Bei strukturierten Daten gibts regelmäßig zusätzlich zu den Daten noch ein Schema-Format, um Kenntnis über die Struktur zu haben und Format-Validierungen zu ermöglichen (XML/XSD/DTD).
Es lässt sich in diesem Repository an Struktur nicht wirklich viel finden, nämlich lediglich
(a) der alphabetischen Repo-Index und
(b) einige Zeilen in jedem Gesetzes-Dateikopf (Ausfertigungsdatum, Fundstelle, Neugefasst durch, Zuletzt geändert durch), sowie
(c) einige Markdown-Tags, etwa "Doppelhash Absatz/Überschrift".
Insgesamt weniger, als auf den seit Jahren gut gepflegten Platformen http://buzer.de, http://openjur.de, http://juris.de/ oder http://gesetze-im-internet.de. Ich kann bislang keine Neuerungen oder Verbesserungen erkennen.
Zudem ist es grotesk, dass bereits bestehende und etablierte XML-Gesetzesstandards des BMJ und der Verwaltung gänzlich ignoriert werden. Ich denke, ihr wollt Euch in den bestehenden Toolchain einklinken und die Arbeit damit verbessern - dann macht das doch einfach mal! Werft mal einen Blick in die UML Spezifikation von xNorm und eNorm. Das Verfahren läuft mit diesen Werkzeugen und nicht mit Git oder auf Github :)
Wir halten fest:
Die Struktur der Daten ist schwach. Es gibt keine Schemadateien. Es gibt kein Pflegemodell.
The text was updated successfully, but these errors were encountered: