Benutzer:LeGast/Zu JSON-LD

Dieser Text bezieht sich auf die ursprüngliche Version (Achtung: Permalink!) des Artikels zu JSON-LD (und wird später voraussichtlich nicht mehr geändert). Er war anfänglich für die zugehörige Diskussionsseite gedacht. Da er jedoch mehr und mehr die dortigen Konventionen zu sprengen schien, steht er hier für sich selbst.

Diskussionen zum Artikelinhalt bitte nicht hier, sondern auf Diskussion:JSON-LD.

Persönliche Mitteilungen an den Autor (soweit unerlässlich:-) bitte vorzugsweise auf Benutzer_Diskussion:LeGast.

Diskrepanzen beim Flattening

(Upps, gleich der erste Mängelbericht vom Artikel-Starter :-) Einerseits ist es nicht mein Stil, bekannte bzw. potenzielle Mängel zu verschweigen. Andererseits wollte ich die „Textspende“ nicht noch in letzter Minute an nicht mehr behebbaren Kleinigkeiten(?) scheitern lassen (was nämlich aufgrund von Zeitmangel und Anspruch ernstlich zur Disposition stand). Oder anders: Ohne diese Randnotiz wäre der Text in seiner derzeitigen Form nicht zu haben gewesen.

Achtung, der folgende Text könnte Dir zu sehr ins Detail gehen oder abschweifend erscheinen. Wenn Dir die nötige Gelassenheit fehlt, besteht kein Grund, sich das anzutun: Lässt es sich doch ziemlich leicht abtun, als das selbstgefällige Geschwätz von jemandem, der sich für sehr geistreich hält. (Auch wenn dieser vorgeben mag, hier in Wirklichkeit ernsthaft einen niederschwelligen Wikipedia-Artikel schaffen zu wollen, welcher dennoch Begriffsinhalt und Wirklichkeit halbwegs gerecht wird :-)

So ist mir erst sehr spät noch aufgefallen, dass im Playground beim Flattening das gewünschte Ergebnis (wie es auch im Artikel steht) nur zu bekommen ist, wenn man eine Fehlermeldung bzw. Warnung provoziert und ignoriert. Konkret: Man erhält ansonsten auch bei leerem Kontext „{}“ im rechten Panel eine compacted Form mit @graph-Member und (zum einzigen Element) kollabierten Arrays. Allein wenn man „null“ eingibt, bleibt es bei einem unauffälligen Warndreieck.

Hintergrund: Ich hatte bis dahin nur das Kommandozeilen-Tool für Node.js aus [1] bzw. die node-en:REPL benutzt. (Bis mir beim Link auf den Playground aufging, dass ja nun jeder *&%$#! die Beispiele dort ausprobieren könne ... :-) (BTW: Auch besagtes Tool hatte noch besorgniserregende Bugs, die nicht gerade mein Vertrauen darin stärken (benutzt und testet das überhaupt jemand?). Soll zwar nicht zu meiner Entschuldigung dienen, aber nach meinem Empfinden ist das alles noch ziemlich Bleeding edge.)

Erste Analyse: Da steckt zwar intern die selbe (Javascript-)Software hinter. Allerdings hängt das Ergebnis davon ab, ob man „null“ oder einen leeren Kontext (Parameter context) übergibt (und im Playground lässt sich hier offenbar kein Nullwert erzeugen ohne gleichzeitig über das rechte Panel eine Beanstandung zu kassieren. Anmerkung: „null“ stellt kein gültiges JSON-LD dar).

Weitere Analyse der Misere: Das Flattening ist etwas überraschender definiert, als mir zunächst bewusst war. (Man lernt so viel aus Fehlern :-) Es beinhaltet optionales Compaction, wenn der context-Parameter eben nicht null ist. Ansonsten wird vor dem Compaction abgebrochen, die Option compactArrays hat keine Wirkung und ein entbehrliches @graph-Member wird eben gerade nicht (unbedingt) zugefügt.

Zu allem Überfluss gibt es noch einen zweiten Playground: http://www.markus-lanthaler.com/jsonld/playground/. Dieser verhält sich hier eindeutig besser: Kein Fehler, wenn man das rechte Panel leer lässt! (Ist daher ebenfalls in den Weblinks gelandet.) Allerdings muss man hier auch erst mal darauf kommen, das vorgegebene „{}“ zu löschen, um das Compaction zu unterdrücken. Die Option compactArrays wird gleichermaßen stiefmütterlich behandelt (wie auch in den Kommandozeilen-Tools).

Was immer auch die (noch nicht befragten) JSON-LD-Gurus dazu noch so alles predigen würden: Mit dem @graph-Dings wollte ich bei der Einführung nicht unnötigerweise ins Haus fallen. Das Flattening wollte ich gerne haben, weil es die blank nodes mit blank node identifiers (also das „_:b0“) versieht, aber ohne das nachgeschaltete Compaction. Und am ersten Teil des Artikels wollte ich deswegen nichts mehr ändern.

Flickwerk: Zu was gänzlich Unverfänglichem konnte ich mich also nicht mehr durchringen. Um dem auf die Schnelle Rechnung zu tragen, habe ich daher im Abschnitt Algorithmen und Formen ansatzweise auf diesen Twist hingewiesen ...

(..., sowie hier einen vorausschauenden Eintrag für die Support-Datenbank hinterlassen: Hinweis an den nächstbesten „Herr Lehrer, Herr Lehrer, ich weiß was, nämlich: dass bei mir was anderes rauskommt“-Typ: Keine Sorge, Du bist nicht allein: bei mir auch! :-) (Above, the damned teacher tried to tell the children that everything is perfectly fine. They should better ignore error messages and warnings in the playground, at least as long as they know what they are doing. Alternatively, they may play in another ground :-)

PS Zwischenzeitlich kamen auch andere schon damit an höherer Stelle angedackelt. (Ich war mal wieder zu früh dran:-) --LeGast (Diskussion) 19:00, 12. Jul. 2014 (CEST)

Original Research?

(... und der zweite auch :-) Mir fehlt da der nötige Abstand: In meinen Kreisen ist das alles Jacki wie Hosi. Normalerweise ist die Erwartung an mich, Neues auszuspucken statt nur Wiedergekäutes. Mit ein Grund, warum Wikipedia anstrengend für mich ist. (Wollte nur darauf hingewiesen haben, um Wikipedia vor irreparablem Schaden zu bewahren :-) Zur Not: Lasst den Artikel halt beim Schwesterchen Wikiversity gründlich durchforschen. (BTW: Wurde von denen hier überhaupt schon mal was zitiert?) --LeGast (Diskussion) 19:00, 12. Jul. 2014 (CEST)

„Merkbild“ fragiler als nötig?

(... und der dritte folgt sogleich:-) Ich vermute, dass sich Besagtes mit Templates und/oder anderen CSS-Klassen oder sogar Wikisyntax robuster gestalten ließe. Denke, dass sich dem sachkundigen Auge aber zumindest die Intention hinter meinem Schnellschuss erschließt. (Eine zweite Version ist zu allem Überfluss auskommentiert: weißer Hintergrund würde mir besser gefallen.) Wollte deswegen nicht extra Inkskape anwerfen bzw. Screenshots machen und Bilder hochladen (und bin halt auch eher Literat (im weitesten Sinne) und würd hier am liebsten auch meine Graphiken „schreiben“, wo ich doch fließend dotisch spreche (wunschgelistet :-). Bevor die Seite dadurch unansehnlich wird, also hier schon mal die Vorwarnung. Würd mich freuen, bei dieser Gelegenheit was lernen zu können. Eine Idee: Wie wär's, das komplett als Template einzubinden? (Bitte auch gleich ein Blick auf die hemdsärmelige Zentrierung in der Tabelle mit den drei JSON-Texten.) --LeGast (Diskussion) 19:00, 12. Jul. 2014 (CEST)

Blogs referenziert, auwaia?

(Schon die vierte Selbstanzeige in Folge:-) Ich meine mich dunkel erinnern zu können, dass Referenzen auf Blogs u.ä. hier verpönt sind. (Wer hat schon Zeit und Lust, sich jedes Jahr wieder das Zeug aus den gefürchteten Meta-Namensräumen durchzulesen oder sich belehren zu lassen, was Wikipedia angeblich alles nicht wäre? Vertraue darauf, das (vermeintlich:-) passende schon um die Ohren gehauen zu bekommen:-) Bevor hier Humorlose reflexartig den Rotstift ansetzen: Von mir ist kein größerer Widerstand zu erwarten. Sie sollen nur einen Moment innehalten und überlegen, was sie da tun: Ich könnte mich nämlich als Autor empfindlich in meinen Freiheitsrechten eingeschränkt fühlen. Und um den Ersatz der dann fehlenden Belege würde ich auch gleich bitten. Zugegeben, kann sein, dass sich mit etwas mehr Recherche (bzw. in X Monaten) „reputablere“, „seriösere“ bzw. „neutralere“ (sowie blutleer polemikfreie) Langweiler-Quellen (aus dem geheiligten Lager der akademischen Springer-und-Co-Exklusiv-Publizierer:-) finden ließen. Aber wer Zeit dadurch spart, Regeln zu befolgen oder durchzusetzen, hat ja vielleicht genau dafür welche übrig. (Ähnlich auch zur ebenfalls referenzierten „grauen“ Dissertations- und Forschungs-Literatur.) (Full incomplete disclosure: Und Nein: Ich bin kein Veganer, habe nichts mit Digital Baazar zu tun, bin kein Spezi von Sporny, hab weder Bockmist beim W3C verbrochen, noch hasse ich jemanden dort dafür, und ich bin auch nicht Markus Lanthaler :-) --LeGast (Diskussion) 19:00, 12. Jul. 2014 (CEST)

Offizielles Logo wäre hübsch ...

(Hört das denn gar nicht auf:-) ... in der Infobox, siehe: http://json-ld.org/images/index.html in Verbindung mit http://www.w3.org/RDF/icons/. Da das W3 leider nicht vollständig loslassen kann und ich nicht den allergeringsten Nerv hab, mich (noch dazu unbezahlt) mit Rechtsfragen rumzuschlagen, hier nur die Anregung, falls jemand da keine unlösbaren Probleme sieht und das auf eigene Kappe durchzieht. Ich sehe ansonsten nur zwei Möglichkeiten, um allen Schwierigkeiten aus dem Weg zu gehen: (1) die Rechteinhaber dazu bewegen, das eigenhändig mit allem (ihrer Meinung nach) unerlässlichen Bla auf Commons hochzuladen, (2) eine Ausnahme in MediaWiki programmieren, dass man speziell diese (u.a.) Icons per img-Element reinsetzen kann. --LeGast (Diskussion) 19:00, 12. Jul. 2014 (CEST)

…ich hab da was auf Commons gefunden und eingebaut. --stk (Diskussion) 14:13, 20. Dez. 2023 (CET)

Zur Anmerkung bzgl. AlbertsIRI

(... auch das noch:-) Hauptgrund für diese Verrenkung: [2] und DBpedia verstanden sich bei mir leider nicht auf Anhieb. Durch einen Hack (am Accept-Header) habe ich das inzwischen (nach entsprechendem Gecurle und Wiregesharke) behoben. (Hauptursache ist zunächst: DBpedia entscheidet sich bei der Auswahl zwischen „ld+json“ und „json“ (ohne q-Parameter-Präferenz für „ld+json“) für (das weiter hinten stehende) „json“, was jedoch nach RFC 2616 zunächst nicht unbedingt zu beanstanden wäre, weil der Defaultwert für den q-Parameter 1.0 ist und dann ggf. auch allein die Server-Präferenz ausschlaggebend wäre, siehe dazu auch: RFC 2296 und RFC 2295; Virtuoso/07.10.3211 meldet ein qs=0.6 für json (sowie für rdf+json) und ein qs=0.5 für ld+json im Content-Type- bzw. sogar im Alternates-Header.) Man kann dem Leser das daher eventuell ersparen (wenn man den Hintergrund kennt), muss es aber nicht. Man lernt so viel aus Fehlern und Zusammenbrüchen ... (Potenziell ist das auch nicht die einzige Kombination, wo das schiefgehen kann und nach Murphys Gesetz auch wird.)

Auch ist es eigentlich kein Thema allein zu JSON-LD und würde (außer zu Content Negotiation) eher zu Linked Data gehören bzw. Cool URI (mal 'n cooles Lemma:-), siehe en:Dereferenceable_Uniform_Resource_Identifier bei den Deutschunkundigen :-) Bei der Content Negotiation dürfte noch so manche Leiche im Keller liegen (und durch verharmlosende Artikel dazu auch weiter in Frieden ruhen :-)

Zum Showstopper DBpedia siehe auch: [3]. Meiner unmaßgeblichen Meinung nach wurde da am Zusammenspiel (auf welcher Seite auch immer) bis heute überhaupt nichts richtig gefixt ... Dies hat im Artikel deshalb a.A. auch im Abschnitt Anforderung von JSON-LD länglichen Niederschlag finden müssen. Die Unstimmigkeiten ziehen sich nämlich im Zusammenspiel mit DBpedia offenbar durch mehrere derzeit verfügbare Implementierungen, die sich (ansonsten) W3C-konform verhalten (sollen): Auch bei RDF Ruby (Beispiel nicht im Artikel) funktioniert die Geburtstags-Demo nur, wenn ich DBpedia nicht gar zu fahrlässig die Wahl lasse, mir auch application/json alias RDF/JSON (!) anzudrehen.

Da dies eventuell ein alternativer Weg wäre, dem Problem im Artikel zu begegnen, hier noch „The Ruby Way“:

require 'json/ld'

JsonLdProcessor = JSON::LD::API

JSON::LD::API::OPEN_OPTS[:headers]['Accept'] =
  "application/ld+json;q=1.0, application/json;q=0.1"

AlbertsIRI = "http://dbpedia.org/resource/Albert_Einstein"
#AlbertsIRI = "http://dbpedia.org/resource/Albert_Einstein.jsonld"

dbpprop = "http://dbpedia.org/property/"
dbpprop_birthDate = dbpprop + "birthDate"

JsonLdProcessor.expand AlbertsIRI do |subjects|
  subjects.each do |subject|
    for object in subject[dbpprop_birthDate] or []
      puts object['@value']
    end
  end
end

(In jsonld.js, das dem Beispiel in CoffeeScript zugrunde liegt, hab ich noch keinen einfachen Weg gefunden, den Header des eingebauten Loaders zu überschreiben. Die Entscheidung für die JavaScript-Implementierung fiel natürlich hauptsächlich, weil sie am nächsten am empfohlenen API liegt (wg. JavaScript-Binding für WebIDL). Persönlich hätte ich allerdings nichts dagegen, das Beispiel im Stile von „Hello JSON-LD“ gnadenlos in allen Programmiersprachen mit JSON-LD-API durchzuspielen – allerdings erst, wenn der Leser seine Inhalts-Präferenzen einstellen könnte: Nach dem Moto: Ich will kein JavaScript sehen, wenn CoffeeScript verfügbar ist, kein Java, wenn Scala, Groovy oder JavaScript erhältlich, Ruby vor Python immer gerne, und C++ oder C nur, wenn nichts anderes da ist, sowie Lisp in diesem Leben nie wieder, dann schon lieber Prolog lebenslänglich ... bzw. auf Mediawikisch: Multilingual description für Programmiersprachen also :-)

In PyLD das selbe Trauerspiel: Um am Accept-Header was zu ändern, müsste gleich ein benutzerdefinierter Loader her (bzw. ein Patch am eingebauten oder ich wäre zu blöd).

Mein (ganz sicher nicht den Tatsachen entsprechender) Eindruck nach einer Woche unmaßgeblicher Erfahrung damit: DBpedia ist nicht mehr auf der Höhe der Zeit oder wird nur noch schleppend gewartet (was ich verstehen könnte, denn ich hab in den offenen Virtuoso-Quellcode reingeschaut:-) Leider zeigt sich auch de.dbpedia.org und die zugehörige Live-Version bzgl. JSON-LD nicht von einer viel besseren Seite: Da bekam ich auch schon mal Turtle statt JSON-LD oder leeres JSON-LD angedreht (und warum da auch noch application/x-json+ld rumgeistert [4], soll Oma nun auch noch begreifen. Wie soll ich ihr erklären, dass es direkt am kryptischen SPARQL-Endpoint ja schon ganz gut zu funktionieren scheint, während es bei Opa Tims coolen URIs noch mächtig hackt? :-) ...

(Für die Dickbrettbohrer hier: Sich auf 'Accept: application/ld+json' zu beschränken kann nicht die Lösung sein. Denn Quellen, welche den LD-Kontext zu ihren json-Daten nur per Link-Header liefern möchten, könnten das als inakzeptable Formatanfrage quittieren. Die Krux scheint mir in einer nicht erschöpfenden Aufzählung aller möglichen Fälle im (etwas sonderlich entweder als Annahme oder als konjunktive Bedingung lesbaren) Schritt 5 bei den API-Methoden zu liegen: Wenn der Content-Type application/json ist, wird ein Link-Header einfach vorausgesetzt. Der Fall eines fehlenden Link-Headers wird gar nicht behandelt, insbesondere nicht als Fehler. Liefert der Server also application/json ohne contextUrl im Link-Header, ist das Verhalten (je nach Lesart) entweder unspezifiziert oder unzweckmäßig (d.h. kein Fehler). Folglich könnte ich nur einen benutzerdefinierten documentLoader empfehlen, welcher bei json-Typen außer application/ld+json und fehlendem Link-Header einen Fehler signalisiert. (Wer nämlich immer schon mal wissen wollte, wie fälschlicherweise als JSON-LD expandiertes oder verflachtes RDF/JSON aussieht: Letztens war das gerade noch billigst unter Verwendung der gängigen Default-Loader im Zusammenspiel mit der seligen DPpedia zu bestaunen :-)

Auch hierbei wären weitergehende Predigten von JSON-LD-Gurus für mich erlässlich: Schließlich wären „wir“ es ja gewohnt, zu jeder freien Software erstmal einen Branch mit den für „uns“ privat unerlässlichen Fixes anzulegen bzw. nicht ausreichend stringenten Specs „unsere“ eigene Interpretation angedeien zu lassen. (Und warum der kommerziellen Konkurrenz einen Vorteil verschaffen, indem man sowas „upstream“ fixen lässt? ;-) Will heißen: Auch an den Tummelplätzen der Geeks und Nerds ist von solchen Lappalien nichts mehr zu lesen; das kommt nur noch alles zum Vorschein, wenn man versucht, seiner (rüstigen) Oma (die zur Aufbesserung der Rente wacker an ihrem Senioren-Mashup strickt:-) und seinen (hochbegabten) Kindern (die mit ihren Touch- und App-(ab)hängigen Altersgenossen nichts anzufangen wissen, als ihnen soziale Netzwerkdienste anzubieten:-) was gaaaaaaanz einfach auf Wikipedia zu erklären. Wer also gerade mit DBpedia und JSON-LD herumdoktert und Deutsch versteht, möchte vielleicht hin und wieder mal in de.Wikipedia gucken, denn hier würde gerade versucht, es massentauglich und volksnah (vermittelbar) zu bekommen :-)

(Es kommt, nebenbei bemerkt, sogar noch dicker: Mit Same-Origin-Policy und Cross-Origin Resource Sharing hat das alles noch gar nichts zu tun! Das kommt in Web-Browsern (auch besonders im Zusammenhang mit Redirects) nur noch erschwerend hinzu ... was ein Grund mehr ist, im Beispiel die format-abhängige URL zu verwenden, um die Unbedarften nicht auch noch in diese Falle tappen zu lassen: DBpedia geruht nämlich zudem, „Access-Control-Allow-Origin“ im „303 See Other“-Redirect nicht zu senden, was Firefox zu veranlassen scheint, ziemlich wortkarg abzubrechen. Ruft man hingegen gleich das Ziel der Weiterleitung auf (also „dbpedia.org/data/Albert_Einstein.jsonld“), klappt's sogar im Browser-Script! Ich will zwar nicht fluchen, aber weniger als „Oma kaum vermittelbar“ kann ich das alles nicht nennen:-)

Wer durch das alles hier nicht durchsteigt, kann eventuell nur soviel mitnehmen: Hier wird wirklich sehr hart daran gearbeitet, es im Artikel möglichst einfach darzustellen. Aber die Wirklichkeit ist leider nicht ganz so einfach. Einige werden daher wohl demnächst die Wirklichkeit vereinfachen müssen ... oder dem Artikel eine ausreichende Länge zugestehen :-) --LeGast (Diskussion) 19:00, 12. Jul. 2014 (CEST)

... und zu Alberts Geburtstag

(... auch noch herzlichen Glückwunsch, DBpedia:-) Wer nämlich das Beispiel zum API ausprobiert (oder am SPARQL-Endpoint rumspielt), wird sich derzeit über das gelieferte Geburtsdatum wundern. Das Gelieferte verstehen zu wollen, bleibt uns aber eventuell gerade noch erspart. Auch wer zu faul ist (oder sonstwie entschuldigt:-), das selbst auszuprobieren, kann hier dazu spicken.

Soll ich nun bereuen, bei den Beispielen auf DBpedia gesetzt zu haben? Oder schreib ich das hier deshalb: Artikel, welche der Wirklichkeit auch nur halbwegs gerecht werden wollen, können gar nicht beliebig kurz sein – auch nicht, wenn sie möglichst einfach sein wollen. (Ähnlichkeiten mit Einsteins „to make the irreducible basic elements as simple and as few as possible“, „simple as possible, but not simpler“ bzw. „so einfach wie möglich, aber nicht einfacher“ sind eventuell nicht nur rein zufällig, sondern sogar beabsichtigt [5] :-)

(Nee, im Ernst: Ich verachte seither diejenigen, die sich mit einem Blick ins (damals noch) „Konversationslexikon“, die Dinge einfach zu machen versuchen. Andererseits gilt: Wenn man keinen halbwegs adäquaten Wikipedia-Artikel dazu schreiben kann, ist der Gegenstand vielleicht generell immer noch zu kompliziert. Und das war hier die mir gestellte Aufgabe: Was ich Lesern der Wikipedia nicht erklären könnte, müsste ich dringend noch mal überdenken (bevor ich es einsetze). Bereuen gibt's da für mich nichts: Wie hätte ich in kürzerer Zeit mehr über das Thema JSON-LD lernen können als bei dem Versuch, einen Wikipedia-Artikel dazu zu schreiben?) Bereuen würde ich nur, wenn die Reaktionen auf meine Beiträge hier zeigen würden, wie tot Wikipedia tatsächlich schon wäre.

Nachdem nun zumindest langsam offenbar würde, dass ich X Monate zu früh damit war bzw. aufs falsche Pferd gesetzt habe (genauer: in meinem jugendlichen Leichtsinn zu viele Abhängigkeiten unter fremder Kontrolle eingegangen bin:-), ein Anflug von Weisheit: Man könnte sich hier natürlich dezent aus der Affäre ziehen, indem man im Beispiel abstrakt mit AnyCoolEntityIRI und AnyCoolPropertyIRI arbeiten würde. Da das aber nicht mein Stil ist (mich aufs Abstrakte zurückzuziehen, um konkrete Blößen zu verschleiern:-), überlass ich das anderen ... --LeGast (Diskussion) 19:00, 12. Jul. 2014 (CEST)

Link auf dbpedia.org bleibt im Spamfilter hängen

(was dann wohl alles erklärt ... :-) https://de.wikipedia.org/wiki/Spezial:Missbrauchsfilter-Logbuch/427770 ... --LeGast (Diskussion) 19:00, 12. Jul. 2014 (CEST)

Virtuoso besser totschweigen?

(... aber zum Glück nicht auch das noch:-) Hätte ich mich im API-Beispiel nicht nur auf Alberts Geburtstags-Literal beschränkt, sondern (im Übermut:-) womöglich auch noch dessen Eltern- oder Ehepartner-Ressourcen (von DBpedia vermittels Virtuoso) abfragen wollen, wäre uns auch folgendes nicht erspart geblieben. Bohrte man nämlich nur geringfügig tiefer ins Brett, zeigten sich weitere Materialfehler: Die in JSON-LD kodierten RDF-Objekte sind durchweg (String-)Literale! Dass das (immerhin) nur am Format liegt, zeigt sich so: In Turtle wird (im Allgemeinen) faktisch ein ganz anderer RDF-Graph übermittelt als in JSON-LD. Nun ließe sich das mit einem geeigneten JSON-LD-Kontext weitgehend beheben. (Und was lässt sich damit – den genialen Schöpfern sei dank – eigentlich nicht beheben? :-) Nur wird ein solcher nicht mitgeliefert. (Und das widerspräche natürlich der ganzen Idee dahinter.)

Turtle:

<http://dbpedia.org/resource/Albert_Einstein>
  <http://dbpedia.org/ontology/spouse>
    <http://dbpedia.org/resource/Mileva_Mari%C4%87> .

Falsch:

{
  "@id": "http://dbpedia.org/resource/Albert_Einstein",
  "http://dbpedia.org/ontology/spouse" : [
    "http://dbpedia.org/resource/Mileva_Mari%C4%87"
  ]
}

Richtig:

{
  "@id": "http://dbpedia.org/resource/Albert_Einstein",
  "http://dbpedia.org/ontology/spouse" : [
    {"@id": "http://dbpedia.org/resource/Mileva_Mari%C4%87"}
  ]
}

Oder mit Kontextes Hilfe:

{
  "@context": {
    "http://dbpedia.org/ontology/spouse": {
      "@type": "@id"
    }
  },
  "@id": "http://dbpedia.org/resource/Albert_Einstein",
  "http://dbpedia.org/ontology/spouse" : [
    "http://dbpedia.org/resource/Mileva_Mari%C4%87"
  ]
}

(Dass unser Eini-Denotat (wie alle außer DBpedia derzeit wissen) zweimal verheiratet war, spielt da (außer eventuell für die unterschlagene Elsa) auch keine Rolle mehr; das weiß zwar Yago immerhin, kränkelt am Virtuoso-Endpunkt aber nicht minder virtuos. Ganz anders http://dbpedialite.org: die weiß zwar gar nichts über Alberts Familienverhältnisse (und auch sonst nicht viel), liefert dafür (dank RDF Ruby) aber astreines JSON-LD – und das sogar bei einem (q-Parameter-freien) Accept-Header, wie ihn die Standardimplementierungen schicken, s.o. :-)

Ich frag mich nun: Dürfte man solches Gebräu überhaupt unter dem Inhaltstyp „application/ld+json“ ausliefern? (Schützt die Rechtsabteilung des W3C ihre Inhaltstypen nicht besser? :-) Oder anders: Sollte das jemand unter diesem Etikett als gleichnamigen Schwindel betrachten, möchte ich damit eigentlich nicht in Verbindung gebracht werden. Deshalb hatte ich überlegt, zumindest den (eventuell etwas zu optimistischen:-) Hinweis darauf zu streichen, dass Virtuoso schon JSON-LD Serialisierung anböte.

Ich möchte nun hiermit wirklich nicht dazu aufgefordert haben, doch bitte die Wirklichkeit endlich dem Artikelinhalt anzupassen. (Sei es auch im Merkelschen Sinne noch so alternativlos:-) Wer das allerdings noch flicken wollte, bevor jemand die Enthüllungen hier läse: „bif_http_ld_json_triple“ schiene mir ein guter Anfang zu sein.

Wenn ich mehr Zeit gehabt hätte (und weniger mit DBpedia/Virtuoso hätte zubringen müssen): Gerne hätte ich auch Jena/Fuskei noch auf seine JSON-LD-Eigenarten abgeklopft. Dort scheint im Februar und Mai einiges zu JSON-LD reingeflossen zu sein. Für die unausrottbaren C-Fans sieht es hingegen finster aus: Unter http://librdf.org/raptor/ heißt es z.Z.: „JSON-LD is not supported - too complex to implement.“ Autsch. :-( Eventuell ein Fall für einen „X nach C“-Compiler, wobei X eine (höhere:-) Sprache ist, in welcher JSON-LD bereits implementiert wurde :-) Nicht minder gerne hätte ich Erfreuliches von Schwesterchen Wikidata bzw. Wikibase (<- rot heißt tot:-) alias mw:Wikibase vermeldet. (Die scheinen mir aber, abgesehen von deren Wiki- und Git-Irrgärten, derweil ganz andere Probleme zu haben: Kinders, ich hab' fast 10 Minuten gebraucht, um rauszufinden, dass die Software hinter Wikidata Wikibase heißt und wo man sich dazu tummelt; nach meinem unmaßgeblichen Zeitempfinden ist das fast soviel wie ein Todesurteil :-) --LeGast (Diskussion) 19:00, 12. Jul. 2014 (CEST)

Nachträge zu Deutschland

(nur noch dies:-) Die DNB scheint mit ihrer Zeitschriftendatenbank langsam in die Puschen zu kommen: [6] [7] Zumindest hatten sie da vor ein paar Tagen schon einen JSON-LD-Kontext. Daten in application/ld+json konnte ich denen aber noch nicht entlocken. Vielleicht schaffen sie es gerade noch in die Liste der frühen Vögel (DPLA scheint mir da schon etwas weiter :-) Tröstlich: Und ich dachte schon, nur ich wäre spät dran ... --LeGast (Diskussion) 19:00, 12. Jul. 2014 (CEST)

Zu wenig Kritik? Zu einseitig?

(... und das:-) Man könnte sicher noch diverse Ansichten zusammentragen, warum JSON-LD nicht „skaliert“ (von wegen Speicherkomplexität bzw. dokument-orientierter Algorithmen), einen JSON-freien „RDF-Stack“ nicht ersetzen kann (von wegen Flexibilität), usw. Obwohl ich ziemlich kritisch bin, versuchte ich aber gegenüber JSON-LD zunächst positiv eingestellt zu sein. Ansonsten befasst man sich nicht wirklich damit, sondern sucht nur nach Gründen, sich nicht damit befassen zu müssen ... (Die Bornierten und Ignoranten dieser Welt wissen, wovon ich schreibe:-)

(Geheimtipp: Die Diskussion um OParls Abkehr (im Artikel verlinkt) bietet einige Munition für die Kritiker :-)

Schreibt das Ding also ruhig (fundiert und fair) in Grund und Boden! Mich juckt das nicht. Hier nur der Hinweis an die Neutralitäts-Polizei, unbedingt noch eine Neutralitäts-Warnung reinzusetzen, wenn man den einseitigen Mist schon anders nicht verbieten kann :-) --LeGast (Diskussion) 19:00, 12. Jul. 2014 (CEST)

Kommentare im Wikitext

(Einer noch:-) Ich hab auf die Schnelle einige Kommentare im Wikitext belassen (Gründe: wollte keine zwei Versionen, hatte kein Plan, wo das hier sonst zu parken wäre, ...). Ahne aber schon, dass das einigen nicht schmecken könnte (von wegen: kann man nur in den Diffs/Quelltexten sehen, Angst vor bösen verstecken Dingen und andere Urängste, ... :-) Bitte um Entschuldigung, falls das jemandem zusätzliche Arbeit macht. Ansonsten vertraue ich auf die ersten erfahrenen Redigierenden, ob rein, raus oder ausbaubar in 'ner Inkubator-Abteilung. --LeGast (Diskussion) 19:00, 12. Jul. 2014 (CEST)

Oh, je: Klammern und Fußnoten

(... und noch einer:-) ... werden manche auch nicht mögen. Klammern sind für mich als Leser der Hinweis: Kann man beim ersten bzw. schnellen Lesen übergehen und verpasst trotzdem erstmal nichts Wesentliches. Für mich als Lektor wären sie der Hinweis: Der Autor war sich entweder nicht sicher, welcher Detailgrad hier (zum Verständnis) angebracht war bzw. suchte noch nach besseren Formulierungen bzw. überlässt dem Lektor die Entscheidung. Oder er hat versucht, den Text für mehrere Verwertungsprofile abzufassen und versteht die Klammern als Hinweis für die „Kürzungsredaktionen“, wo man den Rotstift zuerst ansetzen könnte.

Am liebsten wäre mir persönlich (als Autor und Leser), wenn der Leser individuell einen „Level of Detail“ wählen könnte, welcher mit steigendem Wert zuerst die geklammerten (Level für Level), dann die Fußnoten und zuletzt die Kommentare einblenden würde. Aber so weit sind wir hier vielleicht noch nicht ... :-)

Meinetwegen seht das alles noch als Entwurf an, der erst noch Wikipedia-tauglich zu werden habe. Aber rechnet nicht damit, dass ich diesen Job leisten werde :-) (Mehr, als hier hin- und wieder Texte zu spenden, die ich für andere Zwecke brauchte, kann ich leider momentan nicht bieten. Und mehr als das unbefristet anhaltende Entwurfsstadium kenne ich ohnehin gar nicht mehr ... :-)

Nur soviel zur klaren Ansage: Wenn ich es den (nicht zahlenden:-) Lesern nicht bereits für zumutbar halten würde, hätte ich nicht gewagt, es (frech und ohne vorausgehende Nachfrage:-) in den Artikelnamensraum zu pflanzen. --LeGast (Diskussion) 19:00, 12. Jul. 2014 (CEST)

Die lieben Literatur-Verweise ...

(... bringen mich zum Wahnsinn :-) weil ich das nur noch seltenst brauche und daher wohl weder Routine noch den entsprechenden Werkzeugkasten parat habe (eine Schande für Autoren, die zum semantischen Web schreiben, ich weiß. Hab in einem früheren Leben auch mal unterwürfig gebibtextet :-) Jedenfalls verließ mich da irgendwann die eiserne Disziplin (die außerdem den Schreibfluss behindert. Desweiteren befürchtete ich vielfach, dass es sowieso bald rausfliegen könnte ...) Wen das stört, der muss nun entweder nacharbeiten oder (alles:-) löschen. Wir wollen hier ja nicht die guten Sitten einreißen lassen :-) (Für mich gibt es aber Wichtigeres als die guten Sitten – z.B.: gute Artikel :-) --LeGast (Diskussion) 19:00, 12. Jul. 2014 (CEST)

(Nur) Section 0 zu lang?

(Nun reicht's aber:-) Ich hab mich erst sehr spät entschlossen, Section 0 zum größten Teil in die neue Section 1 fließen zu lassen (wo ich dann auch noch die Syntax angeflanscht habe). Hauptsächlich störte mich, dass das Inhaltsverzeichnis vorher erst so spät kam. Mehr als das schwülstige „Abgrenzung und Einordnung“ ist mir dann nicht mehr zu Betitelung eingefallen. Nun stellt sich aber dadurch auch die Frage, ob man das nicht alles noch weiter nach hinten schiebt, damit die Leser nicht bei den Grundlagen schon müde bzw. von den ganzen fachlichen Querbezügen abgeschreckt sind. (Ich selbst bin der Typ: „Zeig mir ein Beispiel, bevor Du mich abgehoben vollfaselst! Dann reden wir weiter.“ Mich tröstet derzeit nur, dass man über das Merkbild am Anfang schon mal was zu sehen bekommt und es einige Verweise auf spätere Abschnitte für die Schnelleinsteiger gibt.)

Wie schlecht es so auch sein mag: Macht was Besseres draus! Kürzt auch sonst ruhig alles (auf Dünnbrettbohrer-Stummelformat:-) zusammen. (Soweit es mich nur persönlich betrifft: Ich hab hier (ähnlich wie bei meinem bescheidenen Beitrag schon im letzten Jahr) nur den Inhalt abgeliefert, den ich als Leser eigentlich gerne schon vorgefunden hätte. Und ich mag keine Artikel, die dann aufhören, wenn es gerade interessant wird :-)

Wenn jemand die Langfassung auf Wikibooks o.Ä. weiterführt, würde ich mich natürlich freuen, durch einen Link im Artikel davon zu erfahren. Für mich hat es seinen Zweck, so wie es ist, aber bereits erfüllt: ich brauch deswegen nicht auf Wikipedia zu verweisen. Ist im Grunde nur 'n Abfallprodukt ... (Hatte (k)eine Sekunde daran gedacht, es einem Verlag anzubieten; Wikipedia hat (konkurrenz- und bieterlos:-) den Zuschlag erhalten. Freue mich deshalb schon auf die Artikel bei Heise und Co. zu dem Thema: Bin gespannt, was von hier (falsch) abgeschrieben wurde, bzw. was ich von den „Kollegen“ dort noch dazu lernen kann – strengt euch an! :-)

(Ich werde mich mit dem Thema und dem Text frühestens wieder im Herbst/Winter befassen, wo ich eventuell JSON-LD in einem Projekt einsetze (bei dem nicht alle Beteiligten ausreichend Englisch können; während ich selbst befürchte, langsam Deutsch zu verlernen bzw. nichts mehr auf Deutsch erklären zu können, wogegen ich dann anzuschreiben versuche; dies nur für diejenigen, welche nach einer Motivation suchen; gegen krankhaftes Misstrauen hilft das natürlich nichts :-) Im Sommer liegt meine (relativ freie) Studien- bzw. Weiterbildungszeit, in der ggf. was für Wikipedia abfallen kann ... aber die ist bereits jetzt schon wieder abgelaufen. Jetzt will man bereits wieder für viel Geld neue sprühende Ideen von mir kaufen, wozu ich den Kopf vollkommen JSON-LD-frei brauche ... Will heißen: Bevor hier Arbeit auf mich zukäme, würde ich eher die Löschung befürworten :-)

Wer zu spät kommt ...

(... wird mit langen Texten bestraft :-) Der beste Weg, mich los zu werden, ist wohl, mir zuvor zu kommen. (Nein, ich gebe ihn nicht gerne, den geschwätzig-neurotischen Technik-Philosophen, aber was sein muss, muss sein: Ich habe den Text sogar in der Hoffnung über zwei Wochen zurückgehalten, dass er der Welt noch erspart bleiben könne. Aber es tat sich nichts, was das ermöglicht hätte, wenngleich u.a. auch die Wende bei OParl zeigt, wie die Dinge sich momentan noch im Fluss befinden :-)

Übrigens (BTW): Letzte Woche schon in BILD gelesen: „Deutschland verpennt JSON-LD“? Nein? Ich auch nicht! Warum eigentlich? (Übersetzung für die Humorbefreiten: Nee, ganz im Ernst: Das lemmatöse Schweigen von de.Wikipedia fast ein halbes Jahr nach Verabschiedung der Empfehlungen konnte ich nicht länger verantworten.)

Das Ding könnte immerhin mal zur Lingua franca der Software-Agenten im Semantic Web avancieren und Skynet zum Sieg verhelfen – denn offensichtlich wurde es von Maschinen ersonnen und arglosen Programmieren von der Matrix eingeflüstert, es ihre Programme (wie Tron) sprechen zu lassen ... Und dass Google zu den Frühkonsumenten gehört, spricht doch ohnehin Bände, wo doch inzwischen nicht nur die Leichtgläubigen wissen, dass Google eine gigantische Assimilations-Maschine ist, die zur Tarnung wie ein globales Unternehmen zu erscheinen versucht :-) --LeGast (Diskussion) 19:00, 12. Jul. 2014 (CEST)

Ist das nun Satire oder nicht?

Die Antwort ist: Genau! Nur soviel ist sicher: Dies ist keine Aktion von Uncyclopedia. (TTBOMK, fehlt unter Liste von Abkürzungen (Netzjargon)?) Die Frage bleibt: „Is’ das Kunst, oder kann das weg?“ bzw. ISBN 978-3-86506-402-8 --LeGast (Diskussion) 19:00, 12. Jul. 2014 (CEST)