Re: [Wikidata-l] Preliminary SPARQL endpoint for Wikidata

2015-03-20 Thread Dmitriy Sintsov
Hi Markus,
Is  ?statement :P31v :Q3624078 .
 FILTER NOT EXISTS { ?statement :P582q ?endDate }
really enough to filter off currently non-existing countries?
Because I have such code in my Python bot:
http://paste.debian.net/162319/
And even with so many filters, there is a bit strange "Kingdom of
Netherlands" which duplicates "Netherlands" but having only few cities.
Dmitriy

On Fri, Mar 20, 2015 at 9:08 PM, Markus Kroetzsch <
markus.kroetz...@tu-dresden.de> wrote:

> Dear all,
>
> Thanks to the people at the Center of Semantic Web Research in Chile [1],
> we have a very first public SPARQL endpoint for Wikidata running. This is
> very preliminary, so do not rely on it in applications and expect things to
> fail, but you may still enjoy some things.
>
> http://milenio.dcc.uchile.cl/sparql
>
> The endpoint has all the data from our current RDF exports in one big
> database [2]. Below this email are some example queries to get you started
> (this is a bit of a learning-by-doing crash course in SPARQL too, but you
> may want to consult a tutorial if you don't know it ;-).
>
> There are some known bugs in the RDF that we will hopefully fix soon [3].
> Also, the service uses a dump that is already a few weeks old now. We are
> more interested in testing functions right now before going production.
> Also, this is a raw API interface, not a proposal for a nice UI.
>
> Feedback (and other interesting queries) are welcome :-)
>
> Cheers,
>
> Markus
>
>
> [1] http://ciws.cl/ -- a joint team from University of Chile and
> Pontificia Universidad Catolica de Chile
> [2] http://tools.wmflabs.org/wikidata-exports/rdf/
> [3] https://github.com/Wikidata/Wikidata-Toolkit/issues?q=is%
> 3Aopen+is%3Aissue+label%3A%22RDF+export%22
>
>
> ==Lighthouses (Q39715) with their English label (LIMIT 100 for demo)==
>
> PREFIX : 
> SELECT *
> WHERE {
>  ?lighthouse a :Q39715 .
>  ?lighthouse rdfs:label ?label FILTER(LANG(?label) = "en")
> } LIMIT 100
>
> (Just paste the query into the box at http://milenio.dcc.uchile.cl/sparql)
>
> The actual query condition is in the WHERE {...} part. Things starting
> with ? are variables. Basic conditions take the form of triples: "subject
> property value". For example, "?lighthouse a :Q39715" looks for things that
> are a lighthouse ("a" is short for "rdf:type" which we use to encode P31
> statements without qualifiers). The dot "." is used as a separator between
> triples.
>
> Note that the label output is a bit cumbersome because you want to filter
> by language (without the FILTER you get all labels in all languages). A
> future UI would better fetch the labels after the query, similar to WDQ, to
> get smaller & faster queries.
>
>
> ==People born in the same place that they died in==
>
> PREFIX : 
> SELECT ?person ?personname ?placename
> WHERE {
>  ?person a :Q5 .
>  ?person :P19c ?place .
>  ?person :P20c ?place .
>  ?person rdfs:label ?personname FILTER(LANG(?personname) = "en") .
>  ?place rdfs:label ?placename FILTER(LANG(?placename) = "en")
> }  LIMIT 100
>
> Here we use a few actual Wikidata properties. Properties in their simple
> form (Entity->Value) use ids with a "c" in the end, like :P19c here. Only
> qualifier-free statements will be available in this form right now. Note
> that we use the variable ?place in two places as a value. This is how we
> query for things that have the same place in both cases.
>
>
> ==People who have Wikipedia (Q52) accounts==
>
> PREFIX : 
> SELECT ?person ?personname ?username
> WHERE {
>   ?person :P553s ?statement .
>   ?statement :P553v :Q52 .
>   ?statement :P554q ?username .
>   ?person rdfs:label ?personname FILTER(LANG(?personname) = "en") .
> } LIMIT 100
>
> This query needs to access qualifiers of a statement for "website account
> on" (P553). To do this in RDF (and SPARQL), we access the statement object
> instead of using simple property :P553c (which would only give us the
> value). The statement is found through an "...s" property; its value is
> found through a "...v" property; its qualifiers are found through "...q"
> properties. Check out the graph in our paper to get the picture (
> http://korrekt.org/page/Introducing_Wikidata_to_the_Linked_Data_Web).
> There you can also find how references are accessed.
>
>
> ==Currently existing countries==
>
> PREFIX : 
> SELECT ?country ?countryName
> WHERE {
>   ?country :P31s ?statement .
>   ?statement :P31v :Q3624078 .
>  FILTER NOT EXISTS { ?statement :P582q ?endDate }
>   ?country rdfs:label ?countryName FILTER(lang(?countryName)="en")
> }
>
> Similar pattern as with the Wikipedia accounts, but now we check that a
> certain qualifier (end time) does not exist. You could also find currently
> married people in this way, etc.
>
>
> ==Descendants of Queen Victoria (Q9439) ==
>
> PREFIX : 
> SELECT DISTINCT *
> WHERE {
>  :Q94

Re: [Wikidata-l] WDQ API fails or very slow

2015-03-03 Thread Dmitriy Sintsov
https://phabricator.wikimedia.org/T89583
"That sounds like they try to update to the live state via the API, but got
stuck in a loop"
Aren't these API read-only and should not update anything? I expected that
results even might be cached via something like Redis.
I relied on them in my Python command line tool. I hope WDQ API will be
available again.
Dmitriy


On Wed, Mar 4, 2015 at 3:12 AM, Magnus Manske 
wrote:

> https://phabricator.wikimedia.org/T89583
>
> On Tue, Mar 3, 2015 at 1:16 PM Lydia Pintscher <
> lydia.pintsc...@wikimedia.de> wrote:
>
>> On Tue, Mar 3, 2015 at 1:55 PM, Dmitriy Sintsov 
>> wrote:
>> > Hi!
>> > I am developing Python command line tool, which fetches and processes
>> items
>> > / properties from WikiData via WDQ API.
>> > http://wdq.wmflabs.org/api_documentation.html
>> > However currently it fails, resulting in nginx proxy 505 gateway
>> time-out
>> > error.
>> > http://wdq.wmflabs.org/api?q=tree[30][150][17,131]%20and%
>> 20claim[138:676555]
>> > Can you restore WDQ queries functionality, please? My Python script
>> depends
>> > on it.
>> > In IRC I've been told that Yuvi Panda or Magnus Manske may help.
>> > Thanks,
>> > Dmitriy
>>
>> Magnus tweeted they're investigating:
>> https://twitter.com/MagnusManske/status/572736927528566784
>>
>>
>> Cheers
>> Lydia
>>
>> --
>> Lydia Pintscher - http://about.me/lydia.pintscher
>> Product 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/681/51985.
>>
>> ___
>> Wikidata-l mailing list
>> Wikidata-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>>
>
> ___
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
>
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l


[Wikidata-l] WDQ API fails or very slow

2015-03-03 Thread Dmitriy Sintsov
Hi!
I am developing Python command line tool, which fetches and processes items
/ properties from WikiData via WDQ API.
http://wdq.wmflabs.org/api_documentation.html
However currently it fails, resulting in nginx proxy 505 gateway time-out
error.
http://wdq.wmflabs.org/api?q=tree[30][150][17,131]%20and%20claim[138:676555]
Can you restore WDQ queries functionality, please? My Python script depends
on it.
In IRC I've been told that Yuvi Panda or Magnus Manske may help.
Thanks,
Dmitriy
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l