Re: [Wikidata] Wikidata geo-coordinates

[Jeroen De Dauw]

Hey,

While this won't help you for data from the SPARQL endpoint, the Geo
library can be of use when
working with coordinates from Wikidata/Wikibase.

https://github.com/DataValues/Geo/

This library is used by Wikibase and can thus both parse the coordinates
coming from the wiki software
and format coordinates to a format the wiki software supports. This library
is also used by
Semantic MediaWiki [0] and the Maps extension [1], so aids interoperability
there as well.

[0] https://www.semantic-mediawiki.org
[1] https://github.com/JeroenDeDauw/Maps#maps

Cheers

--
Jeroen De Dauw | www.EntropyWins.wtf  |
www.Professional.Wiki 
Software Crafter | Entrepreneur | Speaker | Strategist | Contributor
to Wikimedia
and Open Source
~=[,,_,,]:3
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Virtuoso hosted Wikidata Instance

[Kingsley Idehen]

On 9/2/19 3:51 PM, Adam Sanchez wrote:
> Hi 
>
> I was able to reduce the load time to 9.1 hours aprox. (32890338 msec)
> in Virtuoso 7.
> I used 6 SSD disks of 1T each with RAID 0 (mdadm software RAID, I have
> not tried with hardware RAID).
> The virtuoso.ini for 256G RAM is
> https://gist.github.com/asanchez75/58d5aed504051c7fbf9af0921c3c9130
> I downloaded the dump from 
> https://dumps.wikimedia.org/wikidatawiki/entities/latest-all.ttl.gz 
> on August 30th, 
> The size is 387G uncompressed and finally the file virtuoso.db is
> 362G. The total number of triples is 9 470 700 617.
> Have a look to the simple patch here (is just a workaround)
> https://github.com/asanchez75/virtuoso-opensource/commit/5d7b1b9b29e53cb8a25bed69f512a150f9f05d50
> You can create your own docker image with that patch using
> https://github.com/asanchez75/docker-virtuoso/tree/brendan
> Check the Dockerfile which retrieves the patch from my forked Virtuoso
> git repository
> https://github.com/asanchez75/docker-virtuoso/blob/brendan/Dockerfile
>
>
> Best,


Great job!

I've granted access to you via your email address so that you can update
the Google Spreadsheet containing configuration details per sample
Virtuoso instances [1]. You can put your data in the Wikidata worksheet [2].

Links:

[1]
https://docs.google.com/spreadsheets/d/1-stlTC_WJmMU3xA_NxA1tSLHw6_sbpjff-5OITtrbFw/edit

[2]
https://docs.google.com/spreadsheets/d/1-stlTC_WJmMU3xA_NxA1tSLHw6_sbpjff-5OITtrbFw/edit#gid=1799898600&range=D4



Kingsley

>
>
>
>
> Le dim. 1 sept. 2019 à 13:38, Edgar Meij  > a écrit :
>
> Thanks for this, Kingsley.
>
> Based on
> 
> https://docs.google.com/spreadsheets/d/1-stlTC_WJmMU3xA_NxA1tSLHw6_sbpjff-5OITtrbFw/edit#gid=1799898600
> (copy-pasted below), it seems that it takes 43 hours to load, is
> that correct?
>
> Also, what is the "patch for geometry" mentioned there? I'm
> assuming that is the patch meant to address
> https://github.com/openlink/virtuoso-opensource/issues/295 and
> https://community.openlinksw.com/t/non-terrestrial-geo-literals/359,
> correct? Is it simply disabling the data validation code? Can you
> share the patch?
>
> Thanks,
> Edgar
>
>
> Other Information 
>   
> Architecture  
>   x86_64
> CPU op-mode(s)
>   32-bit, 64-bit
> Byte Order
>   Little Endian
> CPU(s)
>   12.00
> On-line CPU(s) list   
>   0-11
> Thread(s) per core
>   2.00
> Core(s) per socket
>   6.00
> Socket(s) 
>   1.00
> NUMA node(s)  
>   1.00
> Vendor ID 
>   GenuineIntel
> CPU family
>   6.00
> Model 
>   63.00
> Model name
>   
> Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz
> Stepping  
>   2.00
> CPU MHz   
>   1,199.92
> CPU max MHz   
>   3,800.00
> CPU min MHz   
>   1,200.00
> BogoMIPS  
>   6,984.39
> Virtualization
>   VT-x
> L1d cache 
>   32K
> L1i cache 
>   32K
> L2 cache  
>   256K
> L3 cache  
>   15360K
> NUMA node0 CPU(s) 
>   0-11
> RAM   
>   128G
>
>   
>   
> wikidata-20190610-all-BETA.ttl
>   383G
> Virtuoso version  
>   
> 07.20.3230 (with patch for geometry)
> Time to load  
>   43 hours
> virtuoso.db   
>   340G
>
>
> On Wed, Aug 14, 2019 at 12:10 AM Kingsley Idehen
> mailto:kide...@openlinksw.com>> wrote:
>
> Hi Everyone,
>
> A little FYI.
>
> We have loaded Wikidata into a Virtuoso instance accessible
> via SPARQL [1]. One benefit is helping to understand Wikidata
> using our Faceted Browsing Interface for Entity Relationship
> Types [2][3].
>
> Links:
>
> [1] http://wikidata.demo.openlinksw.com/sparql -- SPARQL endpoint
>
> [2] http://wikidata.demo.openlinksw.com/fct -- Faceted
> Browsing Interface
>
> [3] About New York
> 
> 
>
>
> Enjoy!
>
> Feedback always welcome too :)
>
> -- 
> Regards,
>
> Kingsley Idehen 
> Founder & CEO 
> OpenLink Software   
> Home Page: http://www.openlinksw.com
> Community Support: https://community.openlinksw.com
> Weblogs (Blogs):
> Company Blog: https://medium.com/openlink-software-blog
> Virtuoso Blog: https://medium.com/virtuoso-blog
> Data Access Drivers Blog: 
> https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers
>
> Personal Weblogs (Blogs):
> Medium Blog: https://medium.com/@kidehen
> Legacy Blogs: http:/

Re: [Wikidata] Wikidata geo-coordinates

[Ettore RIZZA]

Is there an elegant way to get data out of wikidata in a format that you
can then fill back into another Wikibase without the pain of such
conversions (like splitting coordinates, changing columns, changing the
prefixes...)

It would probably be easier for you to get longitude and latitude
separately, but if I understand correctly the SPARQL query is not the most
straightforward: https://w.wiki/7ny

Cheers,

Ettore Rizza


On Mon, 2 Sep 2019 at 21:34, Olaf Simons 
wrote:

> Cool,
>
> that is a very useful link for us to keep an eye on!
>
> Thanks,
> Olaf
>
>
> > Jan Macura  hat am 2. September 2019 um 21:22
> geschrieben:
> >
> >
> > On Mon, 2 Sep 2019 at 21:11, Olaf Simons  >
> > wrote:
> >
> > > This might be then the central thing to have in the next QueryService
> > > Version: In addition to the present download formats an option to get
> a csv
> > > or tsv output that can be put into QuickStatements for another Wikibase
> > > without tedious conversions.
> > >
> >
> > Well, this is probably more on the QuickStatements site, to allow input
> in
> > a form of WKT...
> >
> >
> > > We will have more and more people with Wikibase installations who will
> use
> > > Wikidata (or other Wikibases) as data source for their platforms.
> > >
> >
> >  Of course. And this is what is currently (yet a bit confusingly) called
> > Federation: https://www.wikidata.org/wiki/Wikidata:Federation_input
> >
> > Best regards,
> >  Jan
> > ___
> > Wikidata mailing list
> > Wikidata@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikidata
>
> Dr. Olaf Simons
> Forschungszentrum Gotha der Universität Erfurt
> Schloss Friedenstein, Pagenhaus
> 99867 Gotha
>
> Büro: +49-361-737-1722
> Mobil: +49-179-5196880
>
> Privat: Hauptmarkt 17b/ 99867 Gotha
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Virtuoso hosted Wikidata Instance

[Adam Sanchez]

Hi

I was able to reduce the load time to 9.1 hours aprox. (32890338 msec) in
Virtuoso 7.
I used 6 SSD disks of 1T each with RAID 0 (mdadm software RAID, I have not
tried with hardware RAID).
The virtuoso.ini for 256G RAM is
https://gist.github.com/asanchez75/58d5aed504051c7fbf9af0921c3c9130
I downloaded the dump from
https://dumps.wikimedia.org/wikidatawiki/entities/latest-all.ttl.gz
on August 30th,
The size is 387G uncompressed and finally the file virtuoso.db is 362G. The
total number of triples is 9 470 700 617.
Have a look to the simple patch here (is just a workaround)
https://github.com/asanchez75/virtuoso-opensource/commit/5d7b1b9b29e53cb8a25bed69f512a150f9f05d50
You can create your own docker image with that patch using
https://github.com/asanchez75/docker-virtuoso/tree/brendan
Check the Dockerfile which retrieves the patch from my forked Virtuoso git
repository
https://github.com/asanchez75/docker-virtuoso/blob/brendan/Dockerfile


Best,




Le dim. 1 sept. 2019 à 13:38, Edgar Meij  a écrit :

> Thanks for this, Kingsley.
>
> Based on
> https://docs.google.com/spreadsheets/d/1-stlTC_WJmMU3xA_NxA1tSLHw6_sbpjff-5OITtrbFw/edit#gid=1799898600
> (copy-pasted below), it seems that it takes 43 hours to load, is that
> correct?
>
> Also, what is the "patch for geometry" mentioned there? I'm assuming that
> is the patch meant to address
> https://github.com/openlink/virtuoso-opensource/issues/295 and
> https://community.openlinksw.com/t/non-terrestrial-geo-literals/359,
> correct? Is it simply disabling the data validation code? Can you share the
> patch?
>
> Thanks,
> Edgar
>
>
> Other Information
> Architecture x86_64
> CPU op-mode(s) 32-bit, 64-bit
> Byte Order Little Endian
> CPU(s) 12.00
> On-line CPU(s) list 0-11
> Thread(s) per core 2.00
> Core(s) per socket 6.00
> Socket(s) 1.00
> NUMA node(s) 1.00
> Vendor ID GenuineIntel
> CPU family 6.00
> Model 63.00
> Model name
> Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz
> Stepping 2.00
> CPU MHz 1,199.92
> CPU max MHz 3,800.00
> CPU min MHz 1,200.00
> BogoMIPS 6,984.39
> Virtualization VT-x
> L1d cache 32K
> L1i cache 32K
> L2 cache 256K
> L3 cache 15360K
> NUMA node0 CPU(s) 0-11
> RAM 128G
> wikidata-20190610-all-BETA.ttl 383G
> Virtuoso version
> 07.20.3230 (with patch for geometry)
> Time to load 43 hours
> virtuoso.db 340G
>
> On Wed, Aug 14, 2019 at 12:10 AM Kingsley Idehen 
> wrote:
>
>> Hi Everyone,
>>
>> A little FYI.
>>
>> We have loaded Wikidata into a Virtuoso instance accessible via SPARQL
>> [1]. One benefit is helping to understand Wikidata using our Faceted
>> Browsing Interface for Entity Relationship Types [2][3].
>>
>> Links:
>>
>> [1] http://wikidata.demo.openlinksw.com/sparql -- SPARQL endpoint
>>
>> [2] http://wikidata.demo.openlinksw.com/fct -- Faceted Browsing Interface
>>
>> [3] About New York
>> 
>>
>> Enjoy!
>>
>> Feedback always welcome too :)
>>
>> --
>> Regards,
>>
>> Kingsley Idehen  
>> Founder & CEO
>> OpenLink Software
>> Home Page: http://www.openlinksw.com
>> Community Support: https://community.openlinksw.com
>> Weblogs (Blogs):
>> Company Blog: https://medium.com/openlink-software-blog
>> Virtuoso Blog: https://medium.com/virtuoso-blog
>> Data Access Drivers Blog: 
>> https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers
>>
>> Personal Weblogs (Blogs):
>> Medium Blog: https://medium.com/@kidehen
>> Legacy Blogs: http://www.openlinksw.com/blog/~kidehen/
>>   http://kidehen.blogspot.com
>>
>> Profile Pages:
>> Pinterest: https://www.pinterest.com/kidehen/
>> Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen
>> Twitter: https://twitter.com/kidehen
>> Google+: https://plus.google.com/+KingsleyIdehen/about
>> LinkedIn: http://www.linkedin.com/in/kidehen
>>
>> Web Identities (WebID):
>> Personal: http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i
>> : 
>> http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this
>>
>> ___
>> Wikidata mailing list
>> Wikidata@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikidata
>>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Wikidata geo-coordinates

[Olaf Simons]

Cool, 

that is a very useful link for us to keep an eye on!

Thanks,
Olaf


> Jan Macura  hat am 2. September 2019 um 21:22 
> geschrieben:
> 
> 
> On Mon, 2 Sep 2019 at 21:11, Olaf Simons 
> wrote:
> 
> > This might be then the central thing to have in the next QueryService
> > Version: In addition to the present download formats an option to get a csv
> > or tsv output that can be put into QuickStatements for another Wikibase
> > without tedious conversions.
> >
> 
> Well, this is probably more on the QuickStatements site, to allow input in
> a form of WKT...
> 
> 
> > We will have more and more people with Wikibase installations who will use
> > Wikidata (or other Wikibases) as data source for their platforms.
> >
> 
>  Of course. And this is what is currently (yet a bit confusingly) called
> Federation: https://www.wikidata.org/wiki/Wikidata:Federation_input
> 
> Best regards,
>  Jan
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata

Dr. Olaf Simons
Forschungszentrum Gotha der Universität Erfurt
Schloss Friedenstein, Pagenhaus
99867 Gotha

Büro: +49-361-737-1722
Mobil: +49-179-5196880

Privat: Hauptmarkt 17b/ 99867 Gotha

___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Wikidata geo-coordinates

[Jan Macura]

On Mon, 2 Sep 2019 at 21:11, Olaf Simons 
wrote:

> This might be then the central thing to have in the next QueryService
> Version: In addition to the present download formats an option to get a csv
> or tsv output that can be put into QuickStatements for another Wikibase
> without tedious conversions.
>

Well, this is probably more on the QuickStatements site, to allow input in
a form of WKT...


> We will have more and more people with Wikibase installations who will use
> Wikidata (or other Wikibases) as data source for their platforms.
>

 Of course. And this is what is currently (yet a bit confusingly) called
Federation: https://www.wikidata.org/wiki/Wikidata:Federation_input

Best regards,
 Jan
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Wikidata geo-coordinates

[Jan Macura]

I am afraid that those questions does not have as simple and
straight-forward answers as the first one...

On Mon, 2 Sep 2019 at 17:39, Olaf Simons 
wrote:

> Is there an elegant way to get data out of wikidata in a format that you
> can then fill back into another Wikibase without the pain of such
> conversions (like splitting coordinates, changing columns, changing the
> prefixes...)
>

I quite agree with what Eugene has written -- it depends what is elegant
for you. Sadly, I have no experience with other Wikibase instances, so I
have no idea how the input for it might look like. But SPARQL has quite
useful string functions that might come handy in this case:
https://en.wikibooks.org/wiki/SPARQL/Expressions_and_Functions#Functions_on_Strings


> Question 2 is related: When you extract dates with the QueryService that
> will change just years like 1971  from 1971-00-00 into 1971-01-01 dates. I
> felt unable to tell whether such a date was just a year or actually a
> January 1 entry. Is there a way to get the exact date as it has been put in
> to Wikibase back from the QueryService?
>

Sorry, I am not familiar with the date representations in Wikibase enough
to provide a meaningful answer.

Best regards,
 Jan
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Wikidata geo-coordinates

[Olaf Simons]

This might be then the central thing to have in the next QueryService Version: 
In addition to the present download formats an option to get a csv or tsv 
output that can be put into QuickStatements for another Wikibase without 
tedious conversions.

We will have more and more people with Wikibase installations who will use 
Wikidata (or other Wikibases) as data source for their platforms.

Maybe I can inspire Magnus...
Thanks,

Olaf

> Eugene Alvin Villar  hat am 2. September 2019 um 17:56 
> geschrieben:
> 
> 
> On Mon, Sep 2, 2019, 11:39 PM Olaf Simons, 
> wrote:
> 
> > Is there an elegant way to get data out of wikidata in a format that you
> > can then fill back into another Wikibase without the pain of such
> > conversions (like splitting coordinates, changing columns, changing the
> > prefixes...)
> >
> 
> Depends on how elegant you want it to be but it won't be trivial. If you
> want to get data from WDQS, you can use any of the available SPARQL
> text/regex manipulation functions to convert the WKT format into a
> different format.
> 
> Question 2 is related: When you extract dates with the QueryService that
> > will change just years like 1971  from 1971-00-00 into 1971-01-01 dates. I
> > felt unable to tell whether such a date was just a year or actually a
> > January 1 entry. Is there a way to get the exact date as it has been put in
> > to Wikibase back from the QueryService?
> >
> 
> Again, this is not trivial. You need to also query the datePrecision field
> of the date value and that means querying for the actual date statement and
> not just the simple value that the usual SPARQL queries provide. Then based
> on the datePrecision value (I think 9 is for year precision vs. 11 for day
> precision), you can then truncate the date to just the year.
> 
> >
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata

Dr. Olaf Simons
Forschungszentrum Gotha der Universität Erfurt
Schloss Friedenstein, Pagenhaus
99867 Gotha

Büro: +49-361-737-1722
Mobil: +49-179-5196880

Privat: Hauptmarkt 17b/ 99867 Gotha

___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Virtuoso hosted Wikidata Instance

[Kingsley Idehen]

On 9/1/19 5:14 AM, Edgar Meij wrote:
> Thanks for this, Kingsley.
>
> Based on
> https://docs.google.com/spreadsheets/d/1-stlTC_WJmMU3xA_NxA1tSLHw6_sbpjff-5OITtrbFw/edit#gid=1799898600
> (copy-pasted below), it seems that it takes 43 hours to load, is that
> correct?


Yes, for that particular single-server instance configuration.


>
> Also, what is the "patch for geometry" mentioned there? I'm assuming
> that is the patch meant to address
> https://github.com/openlink/virtuoso-opensource/issues/295 and
> https://community.openlinksw.com/t/non-terrestrial-geo-literals/359,
> correct? Is it simply disabling the data validation code? Can you
> share the patch?


Best we move this particular item to our community forum [1].

Links:

[1] https://community.openlinksw.com


Kingsley

>
> Thanks,
> Edgar
>
>
> Other Information 
>   
> Architecture  
>   x86_64
> CPU op-mode(s)
>   32-bit, 64-bit
> Byte Order
>   Little Endian
> CPU(s)
>   12.00
> On-line CPU(s) list   
>   0-11
> Thread(s) per core
>   2.00
> Core(s) per socket
>   6.00
> Socket(s) 
>   1.00
> NUMA node(s)  
>   1.00
> Vendor ID 
>   GenuineIntel
> CPU family
>   6.00
> Model 
>   63.00
> Model name
>   
> Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz
> Stepping  
>   2.00
> CPU MHz   
>   1,199.92
> CPU max MHz   
>   3,800.00
> CPU min MHz   
>   1,200.00
> BogoMIPS  
>   6,984.39
> Virtualization
>   VT-x
> L1d cache 
>   32K
> L1i cache 
>   32K
> L2 cache  
>   256K
> L3 cache  
>   15360K
> NUMA node0 CPU(s) 
>   0-11
> RAM   
>   128G
>
>   
>   
> wikidata-20190610-all-BETA.ttl
>   383G
> Virtuoso version  
>   
> 07.20.3230 (with patch for geometry)
> Time to load  
>   43 hours
> virtuoso.db   
>   340G
>
>
> On Wed, Aug 14, 2019 at 12:10 AM Kingsley Idehen
> mailto:kide...@openlinksw.com>> wrote:
>
> Hi Everyone,
>
> A little FYI.
>
> We have loaded Wikidata into a Virtuoso instance accessible via
> SPARQL [1]. One benefit is helping to understand Wikidata using
> our Faceted Browsing Interface for Entity Relationship Types [2][3].
>
> Links:
>
> [1] http://wikidata.demo.openlinksw.com/sparql -- SPARQL endpoint
>
> [2] http://wikidata.demo.openlinksw.com/fct -- Faceted Browsing
> Interface
>
> [3] About New York
> 
> 
>
>
> Enjoy!
>
> Feedback always welcome too :)
>
> -- 
> Regards,
>
> Kingsley Idehen 
> Founder & CEO 
> OpenLink Software   
> Home Page: http://www.openlinksw.com
> Community Support: https://community.openlinksw.com
> Weblogs (Blogs):
> Company Blog: https://medium.com/openlink-software-blog
> Virtuoso Blog: https://medium.com/virtuoso-blog
> Data Access Drivers Blog: 
> https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers
>
> Personal Weblogs (Blogs):
> Medium Blog: https://medium.com/@kidehen
> Legacy Blogs: http://www.openlinksw.com/blog/~kidehen/
>   http://kidehen.blogspot.com
>
> Profile Pages:
> Pinterest: https://www.pinterest.com/kidehen/
> Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen
> Twitter: https://twitter.com/kidehen
> Google+: https://plus.google.com/+KingsleyIdehen/about
> LinkedIn: http://www.linkedin.com/in/kidehen
>
> Web Identities (WebID):
> Personal: http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i
> : 
> http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org 
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata


-- 
Regards,

Kingsley Idehen   
Founder & CEO 
OpenLink Software   
Home Page: http://www.openlinksw.com
Community Support: https://community.openlinksw.com
Weblogs (Blogs):
Company Blog: https://medium.com/openlink-software-blog
Virtuoso Blog: https://medium.com/virtuoso-blog
Data Access Drivers Blog: 
https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers

Personal Weblogs (Blogs):
Medium Blog: https://medium.com/@kidehen
Legacy Blogs: http://www.openlinksw.com/blog/~kidehen/
  http://kidehen.blogspot.com

Profile Pages:
Pinterest: https://www.pinterest.com/kidehen/
Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen
Twitter: https://twitter.com/kidehen
Google+: https://plus.google.com/+KingsleyIdehen/about
LinkedIn:

Re: [Wikidata] Wikidata geo-coordinates

[Sebastian Hellmann]

Hi Olaf

https://databus.dbpedia.org/dbpedia/wikidata/geo-coordinates/2019.08.01 
has monthly (around the 7th) extractions of Wikidata's geo-coordinates.


The website still has a bug and the download links are currently not 
displayed any more at the bottom. But you can query for the latest version.


https://databus.dbpedia.org/yasgui/

PREFIX dataid: 
PREFIX dct: 
PREFIX dcat:  

SELECT ?downloadURL ?sha256sum WHERE {
        ?dataset dataid:artifact 
 .

    ?dataset dcat:distribution/dcat:downloadURL ?downloadURL .
    ?dataset dcat:distribution/dataid:sha256sum ?sha256sum .
        ?dataset dct:hasVersion ?version .

} ORDER BY DESC (?version) LIMIT 1

-- Sebastian


On 02.09.19 17:56, Eugene Alvin Villar wrote:
On Mon, Sep 2, 2019, 11:39 PM Olaf Simons, 
> wrote:


Is there an elegant way to get data out of wikidata in a format
that you can then fill back into another Wikibase without the pain
of such conversions (like splitting coordinates, changing columns,
changing the prefixes...)


Depends on how elegant you want it to be but it won't be trivial. If 
you want to get data from WDQS, you can use any of the available 
SPARQL text/regex manipulation functions to convert the WKT format 
into a different format.


Question 2 is related: When you extract dates with the
QueryService that will change just years like 1971  from
1971-00-00 into 1971-01-01 dates. I felt unable to tell whether
such a date was just a year or actually a January 1 entry. Is
there a way to get the exact date as it has been put in to
Wikibase back from the QueryService?


Again, this is not trivial. You need to also query the datePrecision 
field of the date value and that means querying for the actual date 
statement and not just the simple value that the usual SPARQL queries 
provide. Then based on the datePrecision value (I think 9 is for year 
precision vs. 11 for day precision), you can then truncate the date to 
just the year.



___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

--
All the best,
Sebastian Hellmann

Director of Knowledge Integration and Linked Data Technologies (KILT) 
Competence Center

at the Institute for Applied Informatics (InfAI) at Leipzig University
Executive Director of the DBpedia Association
Projects: http://dbpedia.org, http://nlp2rdf.org, 
http://linguistics.okfn.org, https://www.w3.org/community/ld4lt 


Homepage: http://aksw.org/SebastianHellmann
Research Group: http://aksw.org
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Wikidata geo-coordinates

[Eugene Alvin Villar]

On Mon, Sep 2, 2019, 11:39 PM Olaf Simons, 
wrote:

> Is there an elegant way to get data out of wikidata in a format that you
> can then fill back into another Wikibase without the pain of such
> conversions (like splitting coordinates, changing columns, changing the
> prefixes...)
>

Depends on how elegant you want it to be but it won't be trivial. If you
want to get data from WDQS, you can use any of the available SPARQL
text/regex manipulation functions to convert the WKT format into a
different format.

Question 2 is related: When you extract dates with the QueryService that
> will change just years like 1971  from 1971-00-00 into 1971-01-01 dates. I
> felt unable to tell whether such a date was just a year or actually a
> January 1 entry. Is there a way to get the exact date as it has been put in
> to Wikibase back from the QueryService?
>

Again, this is not trivial. You need to also query the datePrecision field
of the date value and that means querying for the actual date statement and
not just the simple value that the usual SPARQL queries provide. Then based
on the datePrecision value (I think 9 is for year precision vs. 11 for day
precision), you can then truncate the date to just the year.

>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Wikidata geo-coordinates

[Olaf Simons]

Thank you Jan for the swift answer
(I wish I had known before this morning's first data input...)



allow me 2 follow-up questions:

Is there an elegant way to get data out of wikidata in a format that you can 
then fill back into another Wikibase without the pain of such conversions (like 
splitting coordinates, changing columns, changing the prefixes...)

Question 2 is related: When you extract dates with the QueryService that will 
change just years like 1971  from 1971-00-00 into 1971-01-01 dates. I felt 
unable to tell whether such a date was just a year or actually a January 1 
entry. Is there a way to get the exact date as it has been put in to Wikibase 
back from the QueryService?

All my thanks,
Olaf





> Jan Macura  hat am 2. September 2019 um 12:20 
> geschrieben:
> 
> 
> Hello Olaf,
> 
> this is a simple one. As it is common in natural language to present the
> world coordinates in order of [latitude, longitude], WKT standard
> ,
> which is used to represent coordinates in the SPARQL endpoint, on the other
> hand, expects an order of [x, y], which in this case means [longitude,
> latitude].
> For more info, see https://en.wikipedia.org/wiki/OGC_GeoSPARQL and
> https://stackoverflow.com/questions/18636564/lat-long-or-long-lat
> 
> So it is a desired behaviour, not a bug ;-)
> 
> Best regards,
>  Jan
> 
> On Mon, 2 Sep 2019 at 12:06, Olaf Simons 
> wrote:
> 
> > I am trying to synchronise FactGrid data with Wikidata.
> >
> > A strange question: If I run a SPARQL search such as this one:
> >
> >
> > https://query.wikidata.org/#SELECT%20%3FGemeinde_in_Deutschland%20%3FGemeinde_in_DeutschlandLabel%20%3Fgeographische_Koordinaten%20WHERE%20%7B%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%22.%20%7D%0A%20%20%3FGemeinde_in_Deutschland%20wdt%3AP31%20wd%3AQ262166.%0A%20%20OPTIONAL%20%7B%20%3FGemeinde_in_Deutschland%20wdt%3AP625%20%3Fgeographische_Koordinaten.%20%7D%0A%7D
> >
> > I get the coordinates with what looks like swapped values:
> >
> > "Point(10.7183 50.9489)" on the QueryService table output
> > "50°56'56"N, 10°43'6"E" on P625 at the respective Wikidata Item Q6986
> >
> > any idea why this is so?
> >
> > Best,
> > Olaf
> >
> >
> >
> >
> > Dr. Olaf Simons
> > Forschungszentrum Gotha der Universität Erfurt
> > Schloss Friedenstein, Pagenhaus
> > 99867 Gotha
> >
> > Büro: +49-361-737-1722
> > Mobil: +49-179-5196880
> >
> > Privat: Hauptmarkt 17b/ 99867 Gotha
> >
> > ___
> > Wikidata mailing list
> > Wikidata@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikidata
> >
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata

Dr. Olaf Simons
Forschungszentrum Gotha der Universität Erfurt
Schloss Friedenstein, Pagenhaus
99867 Gotha

Büro: +49-361-737-1722
Mobil: +49-179-5196880

Privat: Hauptmarkt 17b/ 99867 Gotha

___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

[Wikidata] Weekly summary #380

[Léa Lacroix]

*Here's your quick overview of what has been happening around Wikidata over
the last week.*
Press, articles, blog posts

   - Working with Structured Data on Commons: A Status Report
   
,
   by Lucas Werkmeister
   - Citation.js: a format-independent, modular bibliography tool for the
   browser and command line , article
   in PeerJ Computer Science (Q27726596)
    by Lars Willighagen (Q45907528)
   
   - A systematic literature review on Wikidata
   

   (paywalled) - Marçal Mora-Cantallops et al.
   - GeneDB and Wikidata
    - Magnus Manske, et
   al.
   - Wikidata from a Research Perspective -- A Systematic Mapping Study of
   Wikidata  - Mariam Farda-Sarbas,
   Claudia Mueller-Birn
   - Enriquecimiento de entidades de Wikidata mediante un modelo de
   descomposición y mapeado de categorías de Wikipedia
    ("Enrichment of Wikidata entities
   through a decomposition model and mapping of Wikipedia categories") - Tomás
   Saorín et al.; text in Spanish

Tool of the week

   - *In this new section, you can share your favourite tool with the other
   Wikidata users. You can add some suggestions here
   
.*
   - Cocoda  is a web application to
   manage mappings between authority files. It supports editing
   Wikidata-mappings including GND
   , Basisklassifikation
   , Regensburg Classification
   , Iconclass
   , and Nomisma
   . Cocoda can be used like
   mix'n'match but for more complex mappings.

Other Noteworthy Stuff

   - The vision and strategy papers for Wikidata and Wikibase
    have been
   published - comments welcome on the talk page
   - Follow-up from Wikimania: you can now give input about the language
   barrier on Wikidata
   
and federating
   Wikibase instances with Wikidata
   
   - New tool: a Python library to create bots, scripts and tools for
   lexicographical data  by
   MichaelSchoenitzer
   
   - There is now a new API parameter to add tags on edits summaries
   
   - soweego  version 1.1 is on its way,
   thanks to a WMF Rapid Grant
   
   - Several job offers related to Wikidata were published in the last few
   weeks:
  - Scribe , a Wikimedia
  Foundation funded software and research project, is looking for
a full-stack
  software engineer 
  - The Wikimedia Foundation is hiring a software engineer
   for its Search
  Platform team, including work on Wikidata Query Service
  - Wikimedia Deutschland is looking for a UX designer
  

  and a full-stack developer
  

  for Wikidata

Did you know?

   - Newest properties
   :
  - General datatypes: access restriction status
  , in defining formula
  
  - External identifiers: RPGGeek ID
  , DIBAVOD ID
  , Fundación Goya en
  Aragón ID , AccuRadio
  artist ID , eSTUDÁNKY ID
  , LongSwimsDB ID
  , WTA trail ID
  , Scribd Item ID
  , Dove.org work ID
  ,

[Wikidata] Wednesday: Technical Advice IRC Meeting

[Raz Shuty]

Sorry for cross-posting!

Reminder: Technical Advice IRC meeting this week **Wednesday 3-4 pm UTC**
on #wikimedia-tech.

Questions can be asked in English!

The Technical Advice IRC Meeting (TAIM) is a weekly support event for
volunteer developers. Every Wednesday, two full-time developers are
available to help you with all your questions about MediaWiki, gadgets,
tools and more! This can be anything from "how to get started" over "who
would be the best contact for X" to specific questions on your project.

If you know already what you would like to discuss or ask, please add your
topic to the next meeting:
https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting

Hope to see you there!

-- 
Raz Shuty
Engineering Manager

Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30 219 158 26-0
https://wikimedia.de

Imagine a world, in which every single human being can freely share in the
sum of all knowledge. That‘s our commitment.

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. 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

Re: [Wikidata] Wikidata geo-coordinates

[Jan Macura]

Hello Olaf,

this is a simple one. As it is common in natural language to present the
world coordinates in order of [latitude, longitude], WKT standard
,
which is used to represent coordinates in the SPARQL endpoint, on the other
hand, expects an order of [x, y], which in this case means [longitude,
latitude].
For more info, see https://en.wikipedia.org/wiki/OGC_GeoSPARQL and
https://stackoverflow.com/questions/18636564/lat-long-or-long-lat

So it is a desired behaviour, not a bug ;-)

Best regards,
 Jan

On Mon, 2 Sep 2019 at 12:06, Olaf Simons 
wrote:

> I am trying to synchronise FactGrid data with Wikidata.
>
> A strange question: If I run a SPARQL search such as this one:
>
>
> https://query.wikidata.org/#SELECT%20%3FGemeinde_in_Deutschland%20%3FGemeinde_in_DeutschlandLabel%20%3Fgeographische_Koordinaten%20WHERE%20%7B%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%22.%20%7D%0A%20%20%3FGemeinde_in_Deutschland%20wdt%3AP31%20wd%3AQ262166.%0A%20%20OPTIONAL%20%7B%20%3FGemeinde_in_Deutschland%20wdt%3AP625%20%3Fgeographische_Koordinaten.%20%7D%0A%7D
>
> I get the coordinates with what looks like swapped values:
>
> "Point(10.7183 50.9489)" on the QueryService table output
> "50°56'56"N, 10°43'6"E" on P625 at the respective Wikidata Item Q6986
>
> any idea why this is so?
>
> Best,
> Olaf
>
>
>
>
> Dr. Olaf Simons
> Forschungszentrum Gotha der Universität Erfurt
> Schloss Friedenstein, Pagenhaus
> 99867 Gotha
>
> Büro: +49-361-737-1722
> Mobil: +49-179-5196880
>
> Privat: Hauptmarkt 17b/ 99867 Gotha
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

[Wikidata] Wikidata geo-coordinates

[Olaf Simons]

I am trying to synchronise FactGrid data with Wikidata.

A strange question: If I run a SPARQL search such as this one:

https://query.wikidata.org/#SELECT%20%3FGemeinde_in_Deutschland%20%3FGemeinde_in_DeutschlandLabel%20%3Fgeographische_Koordinaten%20WHERE%20%7B%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%22.%20%7D%0A%20%20%3FGemeinde_in_Deutschland%20wdt%3AP31%20wd%3AQ262166.%0A%20%20OPTIONAL%20%7B%20%3FGemeinde_in_Deutschland%20wdt%3AP625%20%3Fgeographische_Koordinaten.%20%7D%0A%7D

I get the coordinates with what looks like swapped values:

"Point(10.7183 50.9489)" on the QueryService table output
"50°56'56"N, 10°43'6"E" on P625 at the respective Wikidata Item Q6986 

any idea why this is so?

Best,
Olaf




Dr. Olaf Simons
Forschungszentrum Gotha der Universität Erfurt
Schloss Friedenstein, Pagenhaus
99867 Gotha

Büro: +49-361-737-1722
Mobil: +49-179-5196880

Privat: Hauptmarkt 17b/ 99867 Gotha

___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata