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