nicht angemeldet
Api json, Inhalte richtig auslesen
Matthias Apselich lesen über eine API eine Seite von WIKIPEDIA aus. https://de.wikipedia.org/w/api.php?action=query&titles=münchen&prop=revisions&rvprop=content&format=json dann hole ich mir über serialize alle Stringinformationen in meine Variable.
$inhalt
Dort sind dann die Inhalt so drin...
.
.
.
{{Infobox Gemeinde in Deutschland
|Gegründet = 1158
|Art = Stadt
|Wappen = Muenchen Kleines Stadtwappen.svg
|Breitengrad = 48/08/14/N
|Längengrad = 11/34/32/E
|Lageplan = Bavaria M (town).svg
|Lageplanbeschreibung = Lage der Landeshauptstadt München im Freistaat Bayern und im Regierungsbezirk Oberbayern
|Bundesland = Bayern
|Regierungsbezirk = Oberbayern
|Höhe = 519
|Fläche = 310.70
|PLZ = 80331–81929, 85540Einige Häuser, die auf Münchner Stadtgebiet liegen und nur von einer Nachbargemeinde aus zugänglich sind, haben eine Postleitzahl aus dem Nummernkreis der entsprechenden Nachbargemeinde. Dies ist z. B. für die Häuser der Herzogstandstraße 100 bis 114 die der Gemeinde [[Haar (bei München)|Haar]] zugewiesene Postleitzahl 85540.
|Vorwahl = 089
|Gemeindeschlüssel = 09162000
|NUTS = DE212
|LOCODE = DE MUC
|Gliederung = [[Liste der Stadtbezirke Münchens|25 Stadtbezirke]]
|Adresse = [[Neues Rathaus (München)|Marienplatz 8]]
80331 München
|Website = [http://www.muenchen.de/ www.muenchen.de]
|Bürgermeister = [[Dieter Reiter]]
|Bürgermeistertitel = [[Münchner Bürgermeister|Oberbürgermeister]]
|Partei = SPD
}}
.
.
.
Die Punkte stehen für weiteren Inhalt.
Jetzt will ich das diese Inhalt in einzelne Variablen kommen. z.B die erste Zeile
|Gegründet = 1158
|Art = Stadt
Im ersten versuch habe ich das so gemacht
//--------------------------------------------
$teil = explode("|Gegründet", $inhalt);
//--------------------------------------------
if (isset($teil[1]))
{
$teil = explode("|Art", $teil[1]);
//--------------------------------------------
$name_gegruendet = $teil[0]; // Teil1
//--------------------------------------------
}
else
{
$name_gegruendet='';
}
// reinigen
$name_gegruendet=str_replace('=','',$name_gegruendet);
Dabei ist mir jetzt aufgefallen:
Was mache ich wenn es nach der ersten Zeile kein |Art gibt?
So und nun die FRage die mich beschäftigt gibt es eine möglichkeit alle Zeile die mit
dem Zeichen | anfangen, also wie hier z.B. |Gegründet anfangen in ein array zu speichern und den wert also nach dem = auch und beim Zeilenvorschub als Ende ansehen.
-
Du kannst es dir leicht machen und einen fertigen Wiki Parser verwenden. Dann kannst du statt den Text einen Syntaxbaum durchsuchen.
-
Tach!
So und nun die FRage die mich beschäftigt gibt es eine möglichkeit alle Zeile die mit dem Zeichen
|anfangen, also wie hier z.B.|Gegründetanfangen in ein array zu speichern und den wert also nach dem = auch und beim Zeilenvorschub als Ende ansehen.Die Syntax lautet
{{TemplateName|parameter1|parameter2|...|parameterN}}oder auch{{TemplateName|name1=value1|name2=value2|...|nameN=valueN}}. Benannte Parameter können auch mit positionalen (unbenannten) gemischt werden. Dass auf der gezeigten Seite Zeilenumbrüche vor den|stehen ist auch nur optionale Formatierung. Es ist also nicht gesagt, dass jeder Parameter auf einer neuen Zeile beginnt. Wenn du das unbedingt zu Fuß extrahieren möchtest, solltest du am|splitten. Aber ganz so einfach ist das auch wieder nicht, denn man kann Template-Aufrufe auch schachteln. Und dann fängst du an, einen Parser zu schreiben, der die verschachtelten{{...}}auflösen kann.dedlfix.
-
Tach!
So und nun die FRage die mich beschäftigt gibt es eine möglichkeit alle Zeile die mit dem Zeichen
|anfangen, also wie hier z.B.|Gegründetanfangen in ein array zu speichern und den wert also nach dem = auch und beim Zeilenvorschub als Ende ansehen.Die Syntax lautet
{{TemplateName|parameter1|parameter2|...|parameterN}}oder auch{{TemplateName|name1=value1|name2=value2|...|nameN=valueN}}.Der Designer dieses JSON hat wohl nicht verstanden worin der Sinn eines abstrakten Datentypes besteht: Nämlich darin, dass Attribute entweder direkt oder über spezielle Methoden addressierbar sind.
Auf jeden Fall ist es unsinnig, sowas hier:
|Gegründet = 1158 |Art = Stadt |Wappen = Muenchen Kleines Stadtwappen.svgals String im Hauptspeicher zu haben der noch extra (proprietär) geparst werden muss für einen wahlfreien Zugriff. Andererseits braucht solch ein String auch keinen JSON für den Transport via HTTP. Also mal wieder ein Beispiel dafür wie mans nicht machen sollte.
PS: Das XML (format=xml) sieht genauso idiotisch (unstrukturiert) aus wie die resultierende Datenstruktur die letztendlich auch nur einen Blob zum Inhalt hat.
-
Tach!
Der Designer dieses JSON hat wohl nicht verstanden worin der Sinn eines abstrakten Datentypes besteht:
Der Designer dieses JSON-Exporters hatte nicht die Absicht, den in Mediawiki-Syntax vorliegenden Inhalt einer Mediawiki-Seite in eine strukturierte Form zu bringen.
Nämlich darin, dass Attribute entweder direkt oder über spezielle Methoden addressierbar sind.
Es ist nicht Ziel der Mediawiki-Syntax, die Daten strukturiert und maschinenauswertbar zu repräsentieren, sondern es geht lediglich darum, menschenlesbare Seiten mit mehr oder weniger Fließtext zu erstellen. Dabei werden Templates für wiederkehrende Gestaltungsaufgaben verwendet. Das ist keine semantische Aufbereitung der Daten. Ein Mediawiki ist genausowenig eine strukturierte Datenbank wie es ein Papierlexikon ist.
Es wäre sicherlich wünschenswert, bekäme man die Daten in semantischer Form. Darum kümmern sich auch Mediawiki-Zusätze wie Semantic Mediawiki. Das ist der bekannteste, aber er ist nicht in der Wikipedia verwendet. Mir ist auch nicht bekannt, dass die Daten in anderer Form semantisch erfasst würden. Insofern ist die Ausgabe der Daten zwar nicht sonderlich geeignet für den Bedarf des OP, aber es war weder die Absicht von Mediawiki noch dieser API-Ausgabe, strukturierte Datenhaltungen zu versorgen.
Auf jeden Fall ist es unsinnig, sowas hier:
|Gegründet = 1158 |Art = Stadt |Wappen = Muenchen Kleines Stadtwappen.svgals String im Hauptspeicher zu haben der noch extra (proprietär) geparst werden muss für einen wahlfreien Zugriff. Andererseits braucht solch ein String auch keinen JSON für den Transport via HTTP. Also mal wieder ein Beispiel dafür wie mans nicht machen sollte.
Oder ein Beispiel des Nichtverstandenhabens. Der Sinn der Mediawiki-API ist es, an die Meta-Daten des Mediawiki zu gelangen. Es ist nicht der Sinn, die Seiteninhalte datenbankartig strukturiert zu repräsentieren. Das geht auch gar nicht, weil dafür keine geeignete Datenhaltung vorhanden ist und auch nicht beabsichtigt war. Der Inhalt einer Seite gespickt mit Formatieranweisungen ist lediglich ein Datum in diesem JSON, und nicht die Hauptperson.
Es wäre ähnlich unsinnig zu kritisieren, dass Quark als eine weiße, feuchte Masse verkauft wird und nicht fein säuberlich in seine chemischen Bestandteile zerlegt.
PS: Das XML (format=xml) sieht genauso idiotisch (unstrukturiert) aus wie die resultierende Datenstruktur die letztendlich auch nur einen Blob zum Inhalt hat.
Works as designed. Man kann aus einem Heuhaufen, der nie die Absicht hatte, eine strukturierte Datenhaltung zu sein, keine strukturierten Daten erhalten, egal in welcher Ausgabeform.
dedlfix.
-
Works as designed. Man kann aus einem Heuhaufen, der nie die Absicht hatte, eine strukturierte Datenhaltung zu sein, keine strukturierten Daten erhalten, egal in welcher Ausgabeform.
Mich würde mal interessieren, wie die Datenhaltung serverseitig ist. ALso DB-Design usw. Immerhin ist ja sowas wie Schlüssel => Wert erkennbar; ein Heuhaufen ist das bestimmt nicht. Aber dass man daraus einen Heuhaufen machen kann, davon bin ich überzeugt ;)
-
Tach!
Mich würde mal interessieren, wie die Datenhaltung serverseitig ist. ALso DB-Design usw.
Es gibt eine Tabelle page, darin sind die Metadaten jeder Seite enthalten und der Seitenname, also 'München' in dem Fall. Es gibt eine Tabelle revision, darin sind die Metadaten aller Bearbeitungsstände enthalten. Und es gibt die Tabelle text, darin ist der Inhalt der jeweiligen Revision als Blob enthalten, so wie ihn der Bearbeiter in der Textarea eingegeben hat.
Immerhin ist ja sowas wie Schlüssel => Wert erkennbar; ein Heuhaufen ist das bestimmt nicht.
Doch, das ist es. Das ist lediglich Text zur Auszeichnung eines Template-Aufrufs (also Markup) innerhalb anderen Textes, so wie mitten in einem HTML-Dokument ein <table>-Tag auftauchen kann, und dieses und nachfolgende <tr>, <td> und Text nebst anderem Markup ebenfalls keine strukturierte Datenhaltung ist, sondern nur eine Auszeichnung (Markup) innerhalb anderen Textes und Markups. Es ist noch nicht einmal gesagt, dass das, was du als Wert zu erkennen glaubst, der eigentliche Wert in der Darstellung der Seite ist. Das damit aufgerufene Template kann daran noch beliebige Manipulationen vornehmen.
dedlfix.
-
.. Das damit aufgerufene Template kann daran noch beliebige Manipulationen vornehmen.
Autsch, Programmlogik im Template ist Mist. Aber irgendwo muss es ja eine Zuordnung von "Platzhalter Name" => "Platzhalter Wert" geben.
Ansonsten danke für die Info ;)
-
Tach!
.. Das damit aufgerufene Template kann daran noch beliebige Manipulationen vornehmen.
Autsch, Programmlogik im Template ist Mist.
Pauschalaussagen sind auch Mist, besonders wenn man das System dazu offensichtlich nicht kennt.
HTML ist zum Beispiel ein ähnliches System, bei dem Inhalte und Logik-Anweisungen gemeinsam enthalten sind. Die Kennzeichnung, welcher Text was ist (Liste, Absatz, Tabellenzelle, Link), ist Logik im Sinne von Anweisungen, die der Browser verarbeitet, um daraus einen Bildschirminhalt zu erstellen.
Kann man grundsätzlich Mist finden, aber was wäre denn die bessere Alternative, Logik (dazu Metadaten) und Inhalt zu trennen, ohne dass die Handhabung unnötig kompliziert wird?
Bei den Mediawiki-Templates hat man die Herausforderung, dass Templates nicht immer nur reine Platzhalterersetzungen sind, sondern da auch mal ein paar ifs und elses verwendet werden können sollen. Zudem darf das System nicht unnötig komplex in der Handhabung werden. Das Element zum Bearbeiten der Wiki-Inhalte ist immer noch im wesentlichen eine Textarea und ein Absende-Button.
Aber irgendwo muss es ja eine Zuordnung von "Platzhalter Name" => "Platzhalter Wert" geben.
Es gibt in Mediawiki keine diesbezügliche Datenhaltung. Das ist nur Text mit mehr oder weniger komplexen Formatieranweisungen darin, den irgendein Bearbeiter schreibt. Ähnlich wie man Programmcode-Dateien als aneinandergereihten Text schreibt und nicht aus einem Datenbankinhalt heraus erzeugt.
Diese "Zuordnungen" sind Parameter-Literale, mit denen das Template aufgerufen wird. In dem Fall sind es benannte Parameter, es gibt aber auch positionale Parameter. Der Template-Parser parst sich das entsprechend und erzeugt anhand der Regeln im Template-Code eine Ausgabe. Danach sind die "Zuordnungen" Geschichte. Im Grunde ist das wie ein Funktionsaufruf in Programmiersprachen, bei dem man ein paar Parameter (benannt oder positioniert) übergibt. Da steht auch nicht zwingend eine strukturierte Datenhaltung als Quelle für die Inhalte dahinter. Der Funktionsaufruf kann mitten in anderem Code stecken und Literale oder Variableninhalte übergeben bekommen.
dedlfix.
-
Pauschalaussagen sind auch Mist, besonders wenn man das System dazu offensichtlich nicht kennt.
Das Ziel dieser "API" Daten plattformunabhänig und maschinenlesbar bereitzustellen, ist hier gründlich in die Hose gegangen, aber sowas von! Da gibt es nichts zu beschönigen.
-
Hallo pl,
Das Ziel dieser "API" Daten plattformunabhänig und maschinenlesbar bereitzustellen, ist hier gründlich in die Hose gegangen, aber sowas von! Da gibt es nichts zu beschönigen.
Es ist nicht das Ziel von Mediawiki, maschinenlesbare Daten bereitzustellen. Ziel ist es, ein HTML-Dokument zu erstellen.
Bis demnächst
Matthias -
Tach!
Pauschalaussagen sind auch Mist, besonders wenn man das System dazu offensichtlich nicht kennt.
Das Ziel dieser "API" Daten plattformunabhänig und maschinenlesbar bereitzustellen, ist hier gründlich in die Hose gegangen, aber sowas von! Da gibt es nichts zu beschönigen.
Nein, das Ziel kann die API recht gut erreichen. Es sind nur eben nicht die Daten abfragbar, die du dir grad vorstellst, sondern lediglich die in Mediawiki-Syntax geschriebenen Seiteninhalte. Die Wikipedia ist eben keine strukturierte Datenbank.
dedlfix.
-
-
-
-
-
-
-
-