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 and documentation for our installation. 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 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

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
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata