Hello, I tried playing with it a bit and noticed an oddity in the JSON format: if the predicate and object are both left unspecified, "P_" keys will sometimes refer to full statement nodes and sometimes to truthy values. An example item with not too many statements where you can witness this is Q26536085:
curl -s -H 'Accept: application/ld+json' 'https://query.wikidata.org/bigdata/ldf?subject=http%3A//www.wikidata.org/entity/Q26536085&predicate=&object=' | jq '.["@graph"] | .[] | select(.["@id"]=="wd:Q26536085")' Right now, I get the following results: "P1216": "wds:Q26536085-FCED904F-7F06-444A-84CE-0AFCE089C92C", "p:P131": { "@id": "wds:Q26536085-44302E43-6F33-4F4A-9783-BD631171BF43" }, "p:P1435": { "@id": "wds:Q26536085-01720F88-7A41-47C6-84FA-74F5E7538CDC" }, "P17": "wds:Q26536085-8D04E875-1CD8-4A53-BCC9-1B8591A4AE78", "p:P31": { "@id": "wds:Q26536085-6CBDDC3D-632A-41C3-8E3B-D9E1D0C103F7" }, "P625": "wds:Q26536085-49F66E15-7AE7-44D6-95CE-A4955734EA07", "wdt:P1216": "1243406", "P131": "wd:Q635457", "P1435": "wd:Q15700834", "wdt:P17": { "@id": "wd:Q145" }, "P31": "wd:Q3947", "wdt:P625": { "@type": "geo:wktLiteral", "@value": "Point(-2.027844 51.36333)" } As you can see, the "P_" key sometimes refers to the full statement node ("wds:_") and sometimes to the direct, truthy value ("wd:Q_"). Where "P_" points to the statement node, there’s also a "wdt:P_" entry (sometimes pointing directly at a string containing the ID, sometimes pointing to an { "@id": _ } object); conversely, where "P_" points to the truthy value, there’s a "p:P_" entry to an { "@id": _ } object. Is there any reason why different representations are chosen? Is this predictable? Is this a bug? Or is this just something you have to work around using the @context information if you want to use the JSON format? (The other data formats don’t seem to have this problem, since they don’t use unprefixed "P_" keys.) Cheers, Lucas On 21.12.2016 09:23, Léa Lacroix wrote: > > Hello all, > > The SPARQL endpoint we are running at http://query.wikidata.org has > several measures in place in order to ensure it stays up and running > and available for everyone, for example the 30 sec query timeout. This > is necessary but also prevents some useful queries from being run. One > way around this is Linked Data Fragments. It allows for some of the > query computation to be done on the client-side instead of our server. > > We have set this up now for testing and would appreciate your testing > and feedback. You can find out more about Linked Data Fragments > <http://linkeddatafragments.org/concept/> and documentation for our > installation > <https://www.mediawiki.org/wiki/Wikidata_query_service/User_Manual#Linked_Data_Fragments_endpoint>. > Also, you can see a demo of client-side SPARQL evaluation and LDF > server usage here: http://ldfclient.wmflabs.org/ > > Please note - it's in no way a production service for anything, just a > proof-of-concept deployment of LDF client. If you like how it works, > you can get it from the source > <https://github.com/LinkedDataFragments/jQuery-Widget.js> and deploy > it on your own setup. > > Feel free to ask Stas (Smalyshev (WMF)) for any further question! > > > -- > Léa Lacroix > Community Communication Manager for Wikidata > > Wikimedia Deutschland e.V. > Tempelhofer Ufer 23-24 > 10963 Berlin > www.wikimedia.de <http://www.wikimedia.de> > > Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. > > Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg > unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das > Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207. > > > _______________________________________________ > Wikidata mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikidata
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Wikidata mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata
