Was bedeutet maschinenlesbar

[Jan]

Hallo,

Die Frage mag etwas naiv klingen, aber hat jemand eine gute Quelle bzw. selbst eine gute Formulierung zur Hand, um zu beschreiben, was maschinenlesbar im Zusammenhang mit XML bedeutet. Ich bin auf der Suche nach einer leicht verständlichen Beschreibung für nicht IT-Profis, um den Unterschied zu verdeutlichen, das XML-Dokumente maschinenlesbare Daten enthalten und sich von einfachen Text oder PDF Dokumenten unterscheiden.

Gruss,
Jan

[Encoder]

Der Inhalt eines pdf ist für Menschen gemacht. In einer Auflistung einer Rechnung sind die einzelnen Positionen für dich gut erkennbar, aber ein Programm tut sich schwer darin eine Struktur zu finden.
In XML sind die Daten strukturiert und mit einem Namen versehen. Ein Programm erkennt also was die Artikelnummer, die Anzahl und der Preis sind. Weils jedes mal dabei steht.
Der Mensch kann das zwar auch lesen und sich zusammenreimen, aber es ist nicht das was letztendlich als Ausgabe eines Programms für den Anwender herauskommt.

[Jörg Reinholz]

Der Inhalt eines pdf ist für Menschen gemacht. In einer Auflistung einer Rechnung sind die einzelnen Positionen für dich gut erkennbar, aber ein Programm tut sich schwer darin eine Struktur zu finden.

Dem kann man begründet widersprechen. Es gibt genug Programme, die das PDF in Graphikformate oder Postskript umwandeln. Es gibt Programme, die können PDF seitenweise neu zusammensetzen und mehr. Hier mal eine liste von meinem Computer:

pdf180             pdf90              pdfchain           pdfetex            pdfinfo            pdfjam-slides6up   pdfopen            pdftex             pdftoppm           pdfunite
pdf270             pdfannotextractor  pdfclose           pdfflip            pdfjam             pdfjoin            pdfpun             pdftk              pdftops
pdf2dsc            pdfatfi            pdfcrop            pdffonts           pdfjam-pocketmod   pdflatex           pdfseparate        pdftocairo         pdftosrc
pdf2ps             pdfbook            pdfdetach          pdfimages          pdfjam-slides3up   pdfnup             pdfshuffler        pdftohtml          pdftotext

Einige davon sind lediglich Aliase bzw. Wrapper für andere mit vorbelegten Optionen bzw. ~Argumenten. An pdfinfo, besonders aber pdftohtml und pdftotext fällt sofort auf, dass diese tatsächlich Informationen aus einer PDF-Datei extrahieren (bzw. das versuchen. weil der vermeintliche Text sich als eingefügte Graphik entpuppen kann, die man wieder erst durch ein ocr-Programm "jagen" müsste).

Zudem gibt es PDFs mit enthaltenen Formularen. Und um diese dem Benutzer präsentieren zu können muss ein Programm ("Maschine") ebenso wie pdfinfo, pdftohtml oder pdftotext die dafür benötigten Informationen lesen können. Ich höre hier auf, denn das reicht für die Aussage "Eine PDF-Datei ist maschinenlesbar".

"Maschinenlesbar" ist nach meiner Auffassung ohnehin jede (nicht "kaputte") Datei.

Beispiel: Ich habe eine mit gzip gepackte Textdatei. Die Maschine kann diese lesen. Der Mensch bräuchte, (wenn er denn eine in lesbaren Zeichen verfügbare Repräsentation hätte oder sich die Bytes mit einem Hexeditor anieht) eine Menge Papier und Zeit um die Information herauszuholen. Diese Datei ist also nicht "menschenlesbar".

Ich nehme diese Datei und jage diese durch "gzip -d" oder zcat und erhalte eine menschenlesbare Textdatei. (falls die Ausgangsdatei menschenlesbar war.)

"Menschenlesbar" sind also Dateien worin ein Mensch ohne "besondere" Hilfsmittel, also mit nicht mehr als einem Textanzeigeprogramm, Informationen finden kann. Von der Sache her kann es auf einem Computer "nur maschinenlesbare" und "menschen- und maschinenlesbare" Dateien geben.

An dieser Stelle endet die Abgrenzung.

Jörg Reinholz

[Mitleser]

Der Inhalt eines pdf ist für Menschen gemacht. In einer Auflistung einer Rechnung sind die einzelnen Positionen für dich gut erkennbar, aber ein Programm tut sich schwer darin eine Struktur zu finden.

Dem kann man begründet widersprechen.

Bei 99% der aktuell im Umlauf befindlichen PDF glaube ich das nicht. Falls Du auf PDF/A-Strategien hinaus wolltest, sieht die Welt vielleicht anders aus. Aber davon hast Du nichts erwähnt.

Es gibt genug Programme, die das PDF in Graphikformate oder Postskript umwandeln. Es gibt Programme, die können PDF seitenweise neu zusammensetzen und mehr. Hier mal eine liste von meinem Computer:

pdftodies [...] pdftojenes [...]
Einige davon sind lediglich Aliase bzw. Wrapper für andere mit vorbelegten Optionen bzw. ~Argumenten. An pdfinfo, besonders aber pdftohtml und pdftotext fällt sofort auf, dass diese tatsächlich Informationen aus einer PDF-Datei extrahieren (bzw. das versuchen. weil der vermeintliche Text sich als eingefügte Graphik entpuppen kann, die man wieder erst durch ein ocr-Programm "jagen" müsste).

Das stimmt schon, ich sehe dennoch keinen Widerspruch zu Encoders Aussage. Klar kann man Inhalte aus PDFs extrahieren, es ist und bleibt aber eine Krücke. Um bei seinem Beispiel "Rechnung" zu bleiben: Wenn Du bei einem PDF hieraus tatsächlich die qualifizierten Informationen extrahieren willst, müsstest Du via pdftotext/pdftohtml zunächst einmal Salat extrahieren (oder ein professionelles Tool zur Datenextraktion verwenden / eigenen Parser schreiben) und ein Script basteln, welches mit irgendeiner Heuristik die eigentlichen Daten extrahiert. Sobald der Chefdesigner der Rechnungsabteilung (LOL) nun aber auf die Idee kommt, die Rechnung noch viel hübscher zu machen, versagt die mühevoll gestrickte komplett und Du musst von vorne anfangen. Solange "Chefdesigner" aber nicht allzu großen Mist gebaut hat, wird ein Mensch die Rechnung immer noch lesen können. Genau das hat Encoder knapp aber eindeutig formuliert.

Zudem gibt es PDFs mit enthaltenen Formularen. Und um diese dem Benutzer präsentieren zu können muss ein Programm ("Maschine") ebenso wie pdfinfo, pdftohtml oder pdftotext die dafür benötigten Informationen lesen können.

Auch das stimmt an sich, widerlegt aber ebenfalls nicht Encoders Aussage.

Ich höre hier auf, denn das reicht für die Aussage "Eine PDF-Datei ist maschinenlesbar".

Auf rein technischer Ebene vielleicht, auf semantischer nicht. Zumindest nicht ohne zusätzliche Ansätze wie PDF/A.

[...]

Den Rest lasse ich so stehen, ist mir zu theoretisch :-)

[M.]

Mahlzeit,

Auf rein technischer Ebene vielleicht, auf semantischer nicht. Zumindest nicht ohne zusätzliche Ansätze wie PDF/A.

Es gibt einige Tools, die Daten einwandfrei aus PDF extrahieren. Die kosten zwar einiges geriebenes, das ist aber kein Grund, deren Existenz zu bestreiten ;)

[Mitleser]

Auf rein technischer Ebene vielleicht, auf semantischer nicht. Zumindest nicht ohne zusätzliche Ansätze wie PDF/A.

Es gibt einige Tools, die Daten einwandfrei aus PDF extrahieren. Die kosten zwar einiges geriebenes, das ist aber kein Grund, deren Existenz zu bestreiten ;)

Dann erleuchte mich mal bitte! Mir würde spontan PDFlib TET als sehr brauchbar einfallen. Aber auch damit allein würde man (bis zur Erreichung der KI, falls es dazu kommt) nie diesselbe Stabilität erreichen, die z.B. eine Rechnung im XML-Format zur maschinellen Weiterverarbeitung erlauben würde. PDF ist zunächst extrem stabil in der visuellen Darstellung, semantisch nur mit Additiven. Das Rechnungsbeispiel hast Du gelesen?

[M.]

Mahlzeit,

Dann erleuchte mich mal bitte!

http://www.setasign.com/

Es gibt noch mehr, da hab ich die Links grad nicht greifbar.

Mir würde spontan PDFlib TET als sehr brauchbar einfallen.

Keine Ahnung, nie benutzt.

Aber auch damit allein würde man (bis zur Erreichung der KI, falls es dazu kommt) nie diesselbe Stabilität erreichen, die z.B. eine Rechnung im XML-Format zur maschinellen Weiterverarbeitung erlauben würde.

Davon war auch nie die Rede. Du hattest behauptet, dass das automatisierte Auslesen von PDFs nur theoretisch möglich ist und das ist falsch. Nur weil es nicht so schön ist, wie XML, ist es machbar auch ohne KI.

PDF ist zunächst extrem stabil in der visuellen Darstellung, semantisch nur mit Additiven. Das Rechnungsbeispiel hast Du gelesen?

Das streitet doch niemand ab.

[Mitleser]

Dann sind wir komplett überein. Nur fürs Protokoll:

Du hattest behauptet, dass das automatisierte Auslesen von PDFs nur theoretisch möglich ist und das ist falsch.

Das habe ich nicht behauptet.

Nur weil es nicht so schön ist, wie XML,

Das habe ich behauptet.

[M.]

Mahlzeit,

Das habe ich nicht behauptet.

Dann habe ich dich falsch verstanden. Sorry :)

[hotti]

hi,

Das Rechnungsbeispiel hast Du gelesen?

Nurmalso nebenbei, falls Du schon einmal einen Shop entwickelt hast: Hier steckt die Rechnung im Warenkorb und der muss nicht zwangsläufig als XML-Datei temporär angelegt werden. Im einfachsten Fall bedient sich der Programmierer eines handelsüblichen Serializers und legt die Datenstruktur (Array) in die Session-Datei (für PHP ist da der Serializer gleich eingebaut). WIE und mit welchem Algorithmus der Serializer oder ein anderer Data-Abstraction-Layer arbeitet und WO der die Daten ablegt, ist letztendlich egal: Performant muss es sein und das Programm muss mit seinen eigenen Daten arbeiten können, das Programm braucht den wahlfreien Zugriff, welcher gewöhnlich über den Hauptspeicher abgewickelt wird (Random Access).

Der Programmierer KANN die Rechnung als XML <Amount currency="EUR">99.99</Amount> aus beliebigen Datenstrukturen heraus erstellen, weil er Programmierer ist und weil es möglicherweise an den Shop angebundene Drittprogramme gibt, die den Rechnungsbetrag nur verstehen, wenn der Schlüssel "Amount" davor und dahinter steht.

Wenn ein 3rd-party-program den Serialize-Algorithm von PHP kennt und auch die in der Sequenz liegende Datenstruktur, kann das auch Rechnungen erzeugen, die ein Plotter druckt ohne dass die Daten in XML verpackt zur Druckerei geschafft werden müssen.

MfG

[Mitleser]

hi,

Das Rechnungsbeispiel hast Du gelesen?

Nurmalso nebenbei, falls Du schon einmal einen Shop entwickelt hast: Hier steckt die Rechnung im Warenkorb und der muss nicht zwangsläufig als XML-Datei temporär angelegt werden.

Ich kann im gesamten Thread keinen Post entdecken, in welchem diese Behauptung aufgestellt wurde. Es ging um die maschinelle Verarbeitung einer Rechnung am Beispiel PDF vs. XML.

[...]

Möchtest Du noch einen Link zu Deinem Framework hinterherwerfen? Ups, schon passiert.

[hotti]

Möchtest Du noch einen Link zu Deinem Framework hinterherwerfen? Ups, schon passiert.

Das kann auch XML erzeugen.

[Mitleser]

Möchtest Du noch einen Link zu Deinem Framework hinterherwerfen? Ups, schon passiert.

Das kann auch XML erzeugen.

Das ist total toll, hat mit der eigentlichen Fragestellung aber leider immer noch nichts zu tun.

[hotti]

Möchtest Du noch einen Link zu Deinem Framework hinterherwerfen? Ups, schon passiert.

Das kann auch XML erzeugen.

Das ist total toll, hat mit der eigentlichen Fragestellung aber leider immer noch nichts zu tun.

Oh, doch, ne ganze Menge. Denn XML ist keineswegs DAS Format für einen maschinenlesbaren Datenaustausch, auch wenn es weit verbreitet ist.

Allein die in der Aufgabenstellung steckende Aussage ".. um den Unterschied zu verdeutlichen, das XML-Dokumente maschinenlesbare Daten enthalten und sich von einfachen Text oder PDF Dokumenten unterscheiden. " ist allenfalls dafür geeignet, für nicht IT-Profis eine bildliche Darstellung dafür zu vermitteln, wie eine Maschine strukturierte Daten, z.B. Schlüssel-Werte-Paare persistent ablegen kann, so dass eine andere Machine daraus die Schlüssel-Werte-Paare wiederherstellen kann.

Um noch einmal auf den Dateibeggriff "Bytesequenz" (Niklaus Wirth) zurückzukommen: Eine Maschine/Programm liest Bytes aus einer Datei. Kommt ein Parser zu Einsatz, der aus den Bytes <Amount currency="EUR">99.99</Amount> eine Datenstruktur wie z.B.

  
$bill = {  
  Amount   => 99.99,  
  currency => 'EUR',  
};  

erstellen muss, wird dieser Parser viel zu tun haben, denn er muss erkennen, wie Daten menschenlesbar in Form von Bytes in der Datei abgelegt sind. Freilich enthält eine XML-Datei maschinenlesbare Daten: Über den Umweg der menschlichen Lesbarkeit. Nicht umsonst habe ich mich in meinem ersten POST an einem Schichtenmodell versucht, in Fakt arbeiten viele Programme nach diesem Modell.

Insofern ist XML kein gutes Beispiel für maschinenlesbare Dateien und bringt eine ganze Reihe von Nachteilen mit sich, die Du im Wiki nachlesen kannst.

[Mitleser]

Möchtest Du noch einen Link zu Deinem Framework hinterherwerfen? Ups, schon passiert.

Das kann auch XML erzeugen.

Das ist total toll, hat mit der eigentlichen Fragestellung aber leider immer noch nichts zu tun.

Oh, doch, ne ganze Menge. Denn XML ist keineswegs DAS Format für einen maschinenlesbaren Datenaustausch, auch wenn es weit verbreitet ist.

Wer zum Henker hat das denn hier behauptet?

Allein die in der Aufgabenstellung steckende Aussage ".. um den Unterschied zu verdeutlichen, das XML-Dokumente maschinenlesbare Daten enthalten und sich von einfachen Text oder PDF Dokumenten unterscheiden. " ist allenfalls dafür geeignet, für nicht IT-Profis eine bildliche Darstellung dafür zu vermitteln [...]

Genau das war des OPs Wunsch...

Um noch einmal auf den Dateibeggriff "Bytesequenz" (Niklaus Wirth) zurückzukommen: [...]

Ja, OK - jetzt bist Du völlig im Thema ;-)

Insofern ist XML kein gutes Beispiel für maschinenlesbare Dateien und bringt eine ganze Reihe von Nachteilen mit sich, die Du im Wiki nachlesen kannst.

Ich mag XML selber nicht sonderlich leiden, aber das ist bzgl. zur Frage des OP _nicht_ relevant. Mach einen Subthread auf "MEINUNG: Most genius data exchange format ever"

[hotti]

hi,

Um noch einmal auf den Dateibeggriff "Bytesequenz" (Niklaus Wirth) zurückzukommen: [...]

Ja, OK - jetzt bist Du völlig im Thema ;-)

Boaahh, Danke :)

Insofern ist XML kein gutes Beispiel für maschinenlesbare Dateien und bringt eine ganze Reihe von Nachteilen mit sich, die Du im Wiki nachlesen kannst.

Für "maschinenlesbarkeit" hätte ich noch das schönes Beispiel "Pixelmap" (ein besserer Begriff fällt mir nicht ein) zum Speichern einer Rastergrafik in einer Datei, wir brauchen:

1. Breite und Höhe
2. zu jedem Pixel die Angaben r,g,b,d

Und das sind alles nur Zahlen welche, auf Byte-Ebene abgebildet, für einen Menschen völlig unverständlich, aber maschinenlesbar sind :)
(mit dem <canvas>-Objekt ist es z.B. möglich, solche Sequenzen zu erzeugen, 2D-Context)

Für r,g,b,d reicht jeweils 1 Byte, die Werte liegen zwischen 0..255. Für Breite und Höhe würden in den meisten Fällen jeweils 2 Bytes reichen, aber wir können ja auch 4 Bytes nehmen. Oder wir speichern ein ganzzahliges Seitenverhältnis, woraus sich über die Dateilänge dann Width and Height errechnen lassen. Eine Sache könnten wir dem Betrachter überlassen: Hoch oder Quer, aber auch diese Information kann irgendwo untergebracht sein :)

Also, ich denke, dass gerade an diesem Beispiel klar wird, was maschinenlesbarkeit eigentlich ist und überhaupt der Begriff der Digitalisierung von Daten.

Kennst Du noch das "Fax"-Spiel: Jeder hat ein Blatt mit Kästchen (2D, x,y). Wer die 6 gewürfelt hat, darf Bilddaten kundgeben, immer paarweise, z.B. Kästchen 3,4 hat Farbe rot usw. Zum Schluss werden die durchgefaxten Bilder bewertet...

Ich mag XML selber nicht sonderlich leiden, aber das ist bzgl. zur Frage des OP _nicht_ relevant. Mach einen Subthread auf "MEINUNG: Most genius data exchange format ever"

Ach das interessiert hier doch keine Sau :)

MfG

[M.]

Mahlzeit,

Mach einen Subthread auf "MEINUNG: Most genius data exchange format ever"

Ach das interessiert hier doch keine Sau :)

Wenn hier Säue mitlesen, dann wäre die Alternative eine saulesbare Sprache ;)

Vielleicht in Anlehnung an Ook! nehmen wir Oink!

[hotti]

Mahlzeit,

Mach einen Subthread auf "MEINUNG: Most genius data exchange format ever"

Ach das interessiert hier doch keine Sau :)

Wenn hier Säue mitlesen, dann wäre die Alternative eine saulesbare Sprache ;)

Und wenn ich mitkriege, wie jemand eine 10MB-Pixelgrafik in XML verpackt, werde ich zur rasenden Wildsau :)

Vielleicht in Anlehnung an Ook! nehmen wir Oink!

Wa!

[hotti]

Insofern ist XML kein gutes Beispiel für maschinenlesbare Dateien und bringt eine ganze Reihe von Nachteilen mit sich, die Du im Wiki nachlesen kannst.

Einer der Nachteile ergibt sich aus der menschlichen Lesbarkeit einer XML-Struktur, denn derartige Dateien sind mit textlichen Mitteln strukturiert.

<Amount currency="EUR">99.99</Amount>

sind Bytes die für den Menschen lesbar sind. Eine Maschine würde sich z.B. damit begnügen:

Amount99.99currencyEUR

Wobei die Maschine nur wissen muss, wieviele Bytes zu lesen sind, um an die Schlüsse "Amount", "currency" und die Werte "99.99", "EUR" zu kommen, die für den wahlfreien Zugriff dann innerhalb der Maschine verfügbar sind.

Dateien byteweise Lesen, das geht viel schneller als erst die Zeichen zu parsen und die Struktur wiederzuherstellen, welche die Beziehungen der Zeichen, aus denen erst Strings gemacht werden müssen, untereinander herstellt.

Perl, PHP, andere Programmiersprachen und mittlerweile auch Javascript können mit Bytes umgehen, so sind Zahlen, welche den Offset in einer Datei beinhalten nicht als Zahl dargestellt, sondern als Bytesequenz. Beispielsweise kann ein Byte die Zahlen 0..255 codieren. Bytes können aneinandergereiht werden in einer bestimmten Byte-Order (Big-, LittleEndian), so können mit 4 Byte (32 Bit) auch sehr große Zahlen in einer Datei abgebildet bzw. codiert werden.

Im Übrigen bin ich nicht der Einzige, der diesbezüglich entwickelt, aber wahrscheinlich der Erste, der auf seiner Website auch demonstriert, wie JavaScript und Perl über maschinenlesbare Sequenzen miteinander kommunizieren und dann auch noch die Grundlagen einer Low-Level-Serialisierung vermittelt.

[Jörg Reinholz]

Das stimmt schon, ich sehe dennoch keinen Widerspruch zu Encoders Aussage. Klar kann man Inhalte aus PDFs extrahieren, es ist und bleibt aber eine Krücke.

Das ist doch alles eine Frage der Definition. "Maschinenlesbar" besagt doch schon als begriff, dass die Maschine nur irgendwas lesen können muss.

Nehmen wir pdftk: Da sind die "relevanten Informationen" z.B. die Seiten und deren Ausrichtung. Die -> jeweilige ganze Seite <- ist die Information.

Nehmen wir pdfinfo: Da sind die "relevanten Informationen" Title, Creator, Producer, CreationDate, ModDate, Tagged, Form, Pages, Encrypted, Page size, Page rot, Optimized, PDF-Version.

Da pdftk die Informationen erhält (und verarbeiten kann) und auch pdfinfo die Informationen anzeigen kann steht fest: PDF ist im Sinne der schon im Begriff umrissenen Definition "Ein Programm kann die Datei öffnen und Informationen extrahieren" maschinenlesbar.

pdftotext und pdftohtml gehen sogar noch weiter und liefern eine menschenlesbare Präsentation (text bzw. html) der im PDF enthaltenen Daten. Was willst man denn noch verlangen um anzuerkennen, dass PDF "maschinenlesbar" ist?

Zu verlangen, dass _beliebig_bestimmte_Informationen_ extrahiert werden können geht beim Begriff "maschinenlesbar" deutlich zu weit.

Jörg Reinholz

[Mitleser]

Das ist doch alles eine Frage der Definition. "Maschinenlesbar" besagt doch schon als begriff, dass die Maschine nur irgendwas lesen können muss.

Wenn Du es darauf runterbrechen möchtest: OK. Aber Encoder schrieb:

Der Inhalt eines pdf ist für Menschen gemacht. In einer Auflistung einer Rechnung sind die einzelnen Positionen für dich gut erkennbar, aber ein Programm tut sich schwer darin eine Struktur zu finden.

Darauf schrieb Jörg Reinholz:

Dem kann man begründet widersprechen. Es gibt genug Programme, die das PDF in Graphikformate oder Postskript umwandeln. Es gibt Programme, die können PDF seitenweise neu zusammensetzen und mehr. Hier mal eine liste von meinem Computer:

Darauf schrieb Mitleser:

Klar kann man Inhalte aus PDFs extrahieren, es ist und bleibt aber eine Krücke.

Wenn Du es jetzt auf die reine Begrifflichkeit Maschinenlesbarkeit reduzieren möchtest, OK. Es passt nur nicht zu Deinem Widerspruch zu Encoders korrekter Aussage, dass ein Programm sich schwer tun wird, einzelne Rechnungspositionen aus einem PDF zu extrahieren.

[Jörg Reinholz]

Wenn Du es jetzt auf die reine Begrifflichkeit Maschinenlesbarkeit reduzieren möchtest, OK. Es passt nur nicht zu Deinem Widerspruch zu Encoders korrekter Aussage, dass ein Programm sich schwer tun wird, einzelne Rechnungspositionen aus einem PDF zu extrahieren.

Diese Aussage habe ich gar nicht bezweifelt - Ich muss da wohl was klarstellen:

Die von mir zitierte Gesamtaussage lautete:

(1) "Der Inhalt eines pdf ist für Menschen gemacht."
(2) "In einer Auflistung einer Rechnung sind die einzelnen Positionen für dich gut erkennbar,"
(3) "aber ein Programm tut sich schwer darin eine Struktur zu finden."

Ich zweifle hinsichtlich:

(1)
Menschen brauchen ein Programm. welches die Inhalte eines PDF anzeigt. Menschenlesbare Dateien kann man mit einem Textreader öffnen und den Inhalt mehr (z.B. ini-Datei, CSV) oder weniger einfach (z.B. XML, HTML) lesen. PDF ist also nur "maschinenlesbar".

(3)
Auch die Inhalte einer PDF-Datei sind (sonst könnten die von mir genannten Programme nicht funktionieren) durchaus strukturiert. Man muss sich nur fragen, wie man denn den Begriff "Struktur" definieren will. Allgemein ist eine Struktur jede (in der IT: umkehrbare) Art der Zusammenfügung. Ob eine Struktur in einem bestimmten Zusammenhang sinnvoll ist, ist (in der IT) immer eine Frage des Zwecks.

Zur originalen Frage von Jan

Ich bin auf der Suche nach einer leicht verständlichen Beschreibung für nicht IT-Profis, um den Unterschied zu verdeutlichen, das XML-Dokumente maschinenlesbare Daten enthalten und sich von einfachen Text oder PDF Dokumenten unterscheiden.

Ich würde es so sagen:

Aus einer, im Sinne einer definierten und bekannten Document-Type-Definition (DTD, "Formatanweisung") wohlgeformten (formal fehlerfreien) XML-Datei kann man unter Verwendung vorhandener, universeller und fehlerfreier Bibliotheken ("einbindbare Programmteile ohne bekannte Fehler") einfach vorbestimmte Informationen extrahieren ("ermitteln und darstellen") lassen.

Das wäre aber eine sehr spezielle Auslegung des Begriffs "maschinenlesbar".

Jörg Reinholz

[Gunnar Bittersmann]

@@Jörg Reinholz:

nuqneH

Menschen brauchen ein Programm. welches die Inhalte eines PDF anzeigt. Menschenlesbare Dateien kann man mit einem Textreader öffnen

Und was ist ein Texteditor, wenn nicht ein Programm? Es besteht kein bedeutender Unterschied zwischen PDF-Datei und Text-Datei. Für erstere braucht man einen PDF-Reader, für zweite ein Texteditor. Für Bilddateien braucht man ein Bildanzeigeprogramm (wobei diese üblicherweise mit verschiendenen Formaten klarkommen: JPEG, GIF, PNG). Für alle aus Nullen und Einsen bestehende Datein braucht man ein Anzeigeprogramm, um sie in menschenlesbare Form zu bringen.

Und alle aus Nullen und Einsen bestehende Datein sind in dem Sinne maschinenlesbar (sonst könnte ein Anzeigeprogramm die Daten ja nicht darstellen).

Das ist aber kaum der Sinn von „maschinenlesbar“, den der OP gemeint hat, sonst hätte er nicht zwischen PDF (dessen Sinn es ist, Texte/Grafiken in einer visuellen Form aufzunehmen, also für den Menschen gemacht – menschenlesbar) und XML (strukturierte Daten, bei der Maschine bekanntem Vokabular auch maschinenlesbar) unterschieden.

Aus einer, im Sinne einer definierten und bekannten Document-Type-Definition (DTD, "Formatanweisung") wohlgeformten (formal fehlerfreien) XML-Datei

Wohlgeformtheit geht ohne DTD o.ä. (wohlgeformt vs. gültig/valide).

Qapla'

[Jörg Reinholz]

Wohlgeformtheit geht ohne DTD o.ä. (wohlgeformt vs. gültig/valide).

Wop! Du hast mich eiskalt beim Begriffe-verwechseln erwischt.

(Der Rest ist graue Theorie bei der gilt, dass fast jede von vielen Meinungen aus jeweils einem bestimmten Betrachtungswinkel richtig ist.)

Jörg Reinholz

[Gunnar Bittersmann]

@@Jörg Reinholz:

nuqneH

Wohlgeformtheit geht ohne DTD o.ä. (wohlgeformt vs. gültig/valide).

Wop! Du hast mich eiskalt beim Begriffe-verwechseln erwischt.

Eselsbrücke ;-)

Qapla'

[hotti]

Der Inhalt eines pdf ist für Menschen gemacht.

Der Inhalt einer PDF-Datei ist für den PDF-Reader gemacht.

In einer Auflistung einer Rechnung sind die einzelnen Positionen für dich gut erkennbar, aber ein Programm tut sich schwer darin eine Struktur zu finden.

Der PDF-Reader weiß sehr wohl, mit welchem Algorithmus die Daten in der PDF-Datei abgelegt sind und tut sich überhaupt nicht schwer, die Daten aus der Datei zu lesen: Er wendet ganz einfach den Algorithmus an.

In XML sind die Daten strukturiert

Das sind sie in der PDF-Datei auch.

und mit einem Namen versehen.

Es gibt ungezählte andere Algorithmen zum Abbilden von Datenstrukturen (Array, String, Hash) auf Bytebene.

Ein Programm erkennt also was die Artikelnummer, die Anzahl und der Preis sind. Weils jedes mal dabei steht.

Schlüssel-Werte-Paare sind selbstverständlich auch auf Byte-Ebene abbildbar, das ist nicht auf XML beschränkt. Guckst Du hier

Der Mensch kann das zwar auch lesen und sich zusammenreimen, aber es ist nicht das was letztendlich als Ausgabe eines Programms für den Anwender herauskommt.

Der Mensch muss die PDF-Datei überhaupt nicht lesen können: Das macht der PDF-Reader.

XML ist nicht die einzige Möglichkeit, Daten strukturiert in Dateien abzubilden!

[Mitleser]

Der Inhalt eines pdf ist für Menschen gemacht.

Der Inhalt einer PDF-Datei ist für den PDF-Reader gemacht.

Wenn Du dich auf den Schritt "Software macht aus PDF Darstellung auf Bildschirm/Papier" beziehst: ja.

In einer Auflistung einer Rechnung sind die einzelnen Positionen für dich gut erkennbar, aber ein Programm tut sich schwer darin eine Struktur zu finden.

Der PDF-Reader weiß sehr wohl, mit welchem Algorithmus die Daten in der PDF-Datei abgelegt sind und tut sich überhaupt nicht schwer, die Daten aus der Datei zu lesen: Er wendet ganz einfach den Algorithmus an.

BTW: Wenn das so einfach wäre, hätte z.B. der FireFox PDF-Reader weniger Probleme mit der korrekten Darstellung von PDF.

In XML sind die Daten strukturiert

Das sind sie in der PDF-Datei auch.

In einem XML sind die Daten zur maschinellen Weiterverarbeitung strukturiert, in einem PDF zur exakten visuellen Darstellung, außer man nimmt PDF/A-Konzepte hinzu.

[...]

XML ist nicht die einzige Möglichkeit, Daten strukturiert in Dateien abzubilden!

Wer hat das denn hier behauptet?

[Gunnar Bittersmann]

@@Jan:

nuqneH

Die Frage mag etwas naiv klingen, aber hat jemand eine gute Quelle bzw. selbst eine gute Formulierung zur Hand, um zu beschreiben, was maschinenlesbar im Zusammenhang mit XML bedeutet. Ich bin auf der Suche nach einer leicht verständlichen Beschreibung für nicht IT-Profis, um den Unterschied zu verdeutlichen, das XML-Dokumente maschinenlesbare Daten enthalten und sich von einfachen Text oder PDF Dokumenten unterscheiden.

Nicht maschinenlesbar:
Stoppok spielt am 15.11.2014 in Berlin im Postbahnhof sein neues Programm „Stoppok mit Band – Popschutz-Tour 2014“. Beginn: 20:00 Uhr. Die Karten kosten 27,50 €.

Für eine Maschine ist das alles nur Textwüste. Sie könnte vielleicht erkennen, dass ##.##.20## ein Datum ist und ##,## € ein Preis. Wie das aber alles zusammenhäng, wird sich ihr eher nicht erschließen.

Maschinenlesbar wird’s durch semantische Auszeichnung, bspw. RDF in XML-Syntax:

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://schema.org/">  
  <MusicEvent>  
    <name>Stoppok mit Band – Popschutz-Tour 2014</name>  
    <performer>  
      <Person>  
        <name>Stoppok</name>  
      </Person>  
    </performer>  
    <startDate rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2014-11-15T20:00+01:00</startDate>  
    <location>  
      <MusicVenue>  
        <address>  
          <PostalAddress>  
            <addressLocality>Berlin</addressLocality>  
          </PostalAddress>  
        </address>  
      </MusicVenue>  
    </location>  
    <offers>  
      <Offer>  
        <price>27,50 €</price>  
      </Offer>  
    </offers>  
  </MusicEvent>  
</rdf:RDF>

Das ist nun für Menschen aber nicht besonders lesbar. Aber man kann auch beides haben, bspw. in HTML/RDFa Lite:

<p vocab="http://schema.org/" typeof="MusicEvent">  
  <span property="performer" typeof="Person"><span property="name">Stoppok</span></span>  
  spielt am <time property="startDate" dateTime="2014-11-15T20:00+01:00">15.11.2014</time>  
  <span property="location" typeof="MusicVenue">  
    <span property="address" typeof="PostalAddress">  
      in <span property="addressLocality">Berlin</span>  
    </span>  
    im <property="name">Postbahnhof</span>  
  </span>  
  sein neues Programm „<span property="name">Stoppok mit Band – Popschutz-Tour 2014</span>“.  
  Beginn: 20:00 Uhr.  
  <span property="offers" typeof="Offer">Die Karten kosten <span property="price">27,50 €</span>.</span>  
</p>

Qapla'

[Gunnar Bittersmann]

@@Gunnar Bittersmann:

nuqneH

Maschinenlesbar wird’s durch semantische Auszeichnung, bspw. RDF in XML-Syntax:

Wobei das eine Maschine auch nur verstehen kann, wenn ihr die Bedeutung der Auszeichnung, d.h. das Vokabular bekannt ist. Ich hab Schema.org verwendet.

Und der Name des Veranstaltungsorts ist verlorengegangen. Gehört da hinein:

      <MusicVenue>  
        <name>Postbahnhof</name>  
        <address>  
          <PostalAddress>  
            <addressLocality>Berlin</addressLocality>  
          </PostalAddress>  
        </address>  
      </MusicVenue>  

Qapla'

[Encoder]

Nichts gegen die Bewertungsfunktion und die Frage, aber warum eine Frage einen Stern bekommt ist mir ja schon schleierhaft. Vor allem noch bevor es überhaupt eine Antwort gibt und selbst dann müsste diese Antwort noch genial sein :-)
Dann wäre die Frage höchstens "interessant", aber nicht "fachlich hilfreich"?!

[MrMurphy]

Hallo,

die Bewertungsfunktion wird hier im Forum doch immer wieder mißbraucht. Ein regelmäßiger Teilnehmer vergibt Sterne für seine Beiträge gleich mal selbst, wenn ihm seine Argumente ausgehen.

Manchmal kann man als User dabei direkt zuschauen.

So hat der Teilnehmer vor einigen Monaten zu einer einzigen Diskussion morgens um etwa fünf Uhr innerhalb von knapp 10 Minuten mehrere Antworten geschrieben, die direkt danach innerhalb von Sekunden alle mit einem Stern versehen waren. Muss man an Schelm sein, wenn man dabei böses denkt?

Gruss

MrMurphy

[Performer]

Hi,

Nichts gegen die Bewertungsfunktion und die Frage, aber warum eine Frage einen Stern bekommt ist mir ja schon schleierhaft.

im Laufe der Jahre habe ich selbst zwei Fragen mit einem Stern bewertet, weil allein die Fragestellung mir einen Erkennnisgewinn brachte und ich dem Fragesteller dankbar war, eine so intelligente und gut vorbereitete Frage hier zu stellen.

Ich lege an die Bewertungsfunktion nicht den Maßstab einer dogmatisch richtigen oder falschen Antwort. Ich habe schon manches Mal meine Zustimmung zu einer Antwort gegeben, auch wenn ich genau wusste, dass sie nicht in allen Punkten „regelkonform“ war. Die Bewertung galt der Antwort als Ganzes.

Versuchte ich selbst zu xhtml-Zeiten noch präzise zu arbeiten, ist mir mit html5 vieles egal geworden, wahrscheinlich auch altersbedingt, aber auch, weil mir die Motivation fehlt, allen gedanklichen Verästelungen der Regel-Urheber folgen zu wollen. Da spielt dann auch mit, dass html-bzw. css-Teilbereiche mal verboten, mal wieder erlaubt werden und mich ein Gefühl von Willkür beschleicht.

Bitte an die Bewertungsfunktion einfach pragmatischere Maßstäbe anlegen.

Ciao, Performer

[hotti]

Nichts gegen die Bewertungsfunktion und die Frage, aber warum eine Frage einen Stern bekommt ist mir ja schon schleierhaft. Vor allem noch bevor es überhaupt eine Antwort gibt und selbst dann müsste diese Antwort noch genial sein :-)
Dann wäre die Frage höchstens "interessant", aber nicht "fachlich hilfreich"?!

Ich wars, tut mir leid, hab mich verklickt.

[Encoder]

Sei dir verziehen :-)
Ich wollte eher darauf raus ob man eine Frage vielleicht mit einem anderen Symbol markieren könnte. Damit nicht eine gute Antwort als gut markiert wird, sondern eine interessante Frage als solches gekennzeichnet wird.
Wäre vielleicht eine Idee?

[hotti]

Sei dir verziehen :-)

Danke :)

Ich wollte eher darauf raus ob man eine Frage vielleicht mit einem anderen Symbol markieren könnte. Damit nicht eine gute Antwort als gut markiert wird, sondern eine interessante Frage als solches gekennzeichnet wird.
Wäre vielleicht eine Idee?

Finde ich auch. Es gibt interessante Fragen. Das Wort Interesse kommt übrigens aus dem Lateinischen und setzt sich zusammen aus inter und esse (dabei sein). Das ist die Eselsbrücke für das Doppel s

Oder so:
Heute Currywurst, Interesse?
(Interesse wird mit ss geschrieben, weil es mit Essen was zu tun hat)

Horst Schlemmerschnitte

[Herrmann]

... um den Unterschied zu verdeutlichen, das XML-Dokumente maschinenlesbare Daten enthalten und sich von einfachen Text oder PDF Dokumenten unterscheiden.

Ein Versuch:

Der Mensch erschließt einen Text semantisch, vom Inhalt her. Hierbei unterstützen ihn u. a. die Wortbedeutungen, stilistische Hinweise und seine eigenen Assoziationen. Für die Maschine ist jeder Text zunächst einen Abfolge bedeutungsloser Zeichen, die nach strukturellen, syntaktischen Gesichtspunkten aufgedröselt werden. Damit sie so agieren kann, _als ob_ sie den Text verstünde, sind Hinweise erforderlich, welche Textteile nach welchem Muster zu behandeln sind.

Gruß H.

[hotti]

Hallo,

Die Frage mag etwas naiv klingen, aber hat jemand eine gute Quelle bzw. selbst eine gute Formulierung zur Hand, um zu beschreiben, was maschinenlesbar im Zusammenhang mit XML bedeutet. Ich bin auf der Suche nach einer leicht verständlichen Beschreibung für nicht IT-Profis, um den Unterschied zu verdeutlichen, das XML-Dokumente maschinenlesbare Daten enthalten und sich von einfachen Text oder PDF Dokumenten unterscheiden.

Dateibegriff nach Niklaus Wirth: Bytesequenz

Maschinenlesbar sind alle Dateien, ein Programm/Script kann Bytesequenzen lesen und schreiben. Eine Datei repräsentiert Daten auf Byte-Ebene, wobei diese Präsentation für die Maschine relevant ist, ein Programm vermittelt von der Byte-Ebene über den programminternen wahlfreien Zugriff auf Daten (Variablen im RAM, z.B. ein Textstring) bis zur Darstellungsebene der Daten in einer für den Menschen verständlichen Form (Text, Audio, Video, Grafik).

Ich versuche mich mal ein einem Schichtenmodell:

-----------------------------------------
| Darstellung (Text, Audio, Video, Grafik |
 -----------------------------------------
| Interface, GUI                          |
 -----------------------------------------
| Programm (PDF-Reader)                   |
 -----------------------------------------
| Serializer (RAM <=> Bytes)              |
 -----------------------------------------
| Datei (Bytesequenz)                     |
 -----------------------------------------

Dieses Schichtenmodell kannst Du auf alle Programme anwenden, z.B. Texteditor, Textbetrachter, Bildbearbeitungsprogramm, Bildbetrachter, PDF-Editor, PDF-Reader, Audio-, Video- usw.

Es wird "schwierig", XML hier anzusiedeln, denn dieses Datenformat durchgreift alle oben dargestellten Schichten. Aus dieser "Schwierigkeit" erwächst jedoch die "Einfachheit" für einen progammübergreifenden und plattformunabhängigen Datenaustausch zwischen Maschinen (Programmen).

So kannst Du mit XML auf Darstellungsebene (Windows-Texteditor) "Variablen" in eine Datei schreiben und ein UNIX-Programm (Perl, XML::Parser) versteht Deine Daten nach dem Lesen der Datei als programminterne Variablen die für den wahlfreien Zugriff im Hauptspeicher (RAM) gehalten werden. XML ist sozusagen die Verpackung für den Transport und fürs Speichern von Daten auf Festplatten außerhalb eines Programms und da ein programm-/plattformunabhängiger Datenauschtausch immer wichtiger wird, oftmals der gemeinsame Nenner für den viele Programme eine Schnittstelle bieten.

MfG

[hotti]

Noch ein schöner PS:
Maschinell werden Dateien (Sequenzen) byteweise oder in Blöcken von Bytes gelesen (sequentiell). Im XML ergeben Blöcke von Bytes überhaupt keinen Sinn, weil die vom Ersteller beabsichtigte Datenstruktur in der Datei nicht blockweise sondern als Text abgelegt ist.

Das bedeutet im Fall XML: Die Maschine muss die GANZE Sequenz einlesen um das vom menschlichen Ersteller angewandte Schema strukturell erkennen zu können.

Abstrakt: Die Maschine muss eine XML-Datei genauso lesen wie ein Mensch.

Ob es immer sinnvoll ist, auf einer Maschine ein menschliches Vorgehen 1:1 abzubilden, sei dahingestellt. Aus meiner Sicht ist es jedoch Unfug, einen Random Access (wahlfreier Zugriff) auf Dateiebene abzubilden, dafür gibt es den RAM (danke Niklaus Wirth). Optimal wäre, die sich vom Menschen deutlich unterschiedlichen Fähigkeiten einer Maschine zum Lesen von Dateien (siehe oben) konsequent zu nutzen.

Schönes Wochenende ;)

[Gunnar Bittersmann]

@@hotti:

nuqneH

Maschinell werden Dateien (Sequenzen) byteweise oder in Blöcken von Bytes gelesen (sequentiell). Im XML ergeben Blöcke von Bytes überhaupt keinen Sinn, weil die vom Ersteller beabsichtigte Datenstruktur in der Datei nicht blockweise sondern als Text abgelegt ist.

Hä?? Willst du damit sagen, XML-Dateien wären menschenlesbar, nicht maschinenlesbar?

Das bedeutet im Fall XML: Die Maschine muss die GANZE Sequenz einlesen um das vom menschlichen Ersteller angewandte Schema strukturell erkennen zu können.

XML-Dateien werden oft von Maschinen (Programmen) erstellt, nicht von Menschen.

Ob es immer sinnvoll ist, auf einer Maschine ein menschliches Vorgehen 1:1 abzubilden, sei dahingestellt.

Keine Ahnung, worauf du hinauswillst.

Aus meiner Sicht ist es jedoch Unfug, einen Random Access (wahlfreier Zugriff) auf Dateiebene abzubilden,

Aus meiner nicht.

Qapla'