Re: [Wikidata] Preferred rank -- choices for infoboxes, versus SPARQL

Hoi, A big city is what? A city with more than a given number of inhabitants? If so it is redundant because it can be inferred. Thanks, GerardM On 28 November 2015 at 06:12, Peter F. Patel-Schneider < pfpschnei...@gmail.com> wrote: > It seems to me that a whitelist is the preferred solution

Re: [Wikidata] Preferred rank -- choices for infoboxes, versus SPARQL

It seems to me that a whitelist is the preferred solution to the problem of displaying too many classes that an item belongs to. Any blacklist solution is going to need revision as new classes are added to Wikidata. Any preference data is going to have problems with different languages and cultur

Re: [Wikidata] Odd results from wdqs

The "absolute" was the char[] size, which I had set to ~1MB back in the day. Subsequent use of STL string type does support any memory-fitting string. On Fri, Nov 27, 2015 at 3:24 PM Markus Krötzsch < mar...@semantic-mediawiki.org> wrote: > On 27.11.2015 15:22, Magnus Manske wrote: > > It was the

Re: [Wikidata] Mix'n'match: how to preserve manually audited items for posterity?

oh I see, what a mess those Grisulfs, the family relationships are totally messed up, off to clean them up. > On Nov 27, 2015, at 10:38 AM, Gerard Meijssen > wrote: > > Hoi, > I do not know how to as there are two candidates. I do not have your book > that helps pick the right one. I have a

Re: [Wikidata] Mix'n'match: how to preserve manually audited items for posterity?

Hoi, I do not know how to as there are two candidates. I do not have your book that helps pick the right one. I have added some statements so that disambiguation is even easier. Reasonator is a great tool :) Thanks, GerardM On 27 November 2015 at 19:35, Dario Taraborelli wrote: > err…point

Re: [Wikidata] Mix'n'match: how to preserve manually audited items for posterity?

err…point me to the correct item or fix it then? WP:BOLD > On Nov 27, 2015, at 10:33 AM, Gerard Meijssen > wrote: > > Hoi, > It is highly likely that your Lombard duke already existed. So I think you > got it wrong. > Thanks, > GerardM > > On 27 November 2015 at 19:31, Dario Taraborelli

Re: [Wikidata] Mix'n'match: how to preserve manually audited items for posterity?

Hoi, It is highly likely that your Lombard duke already existed. So I think you got it wrong. Thanks, GerardM On 27 November 2015 at 19:31, Dario Taraborelli wrote: > Gerard – I think you’re missing my point. I’m not suggesting this as a > display feature (which would be welcome and can alw

Re: [Wikidata] Mix'n'match: how to preserve manually audited items for posterity?

Gerard – I think you’re missing my point. I’m not suggesting this as a display feature (which would be welcome and can always be generated by any tool querying Wikidata labels) but as a contribution stored to avoid future errors. > On Nov 27, 2015, at 10:29 AM, Gerard Meijssen > wrote: > > Ho

Re: [Wikidata] Mix'n'match: how to preserve manually audited items for posterity?

Hoi, Why not use Reasonator? https://tools.wmflabs.org/reasonator/?find=Grasulfo Thanks, GerardM On 27 November 2015 at 19:26, Dario Taraborelli wrote: > Magnus, this is fantastic and works as expected, thanks a lot. > > One last note regarding the use of *different from* (P1889 >

Re: [Wikidata] Mix'n'match: how to preserve manually audited items for posterity?

Magnus, this is fantastic and works as expected, thanks a lot. One last note regarding the use of different from (P1889 ). While I agree with you that it would be overkill to generate all these relations for common homonyms, for new items created by

Re: [Wikidata] Preferred rank -- choices for infoboxes, versus SPARQL

On 27.11.2015 17:05, Tobias Schönberg wrote: @Markus, James: In my opinion it is better to make the query ask for the most recent population number. People just need to start using time-qualifiers for things like census-report numbers. Unfortunately, this is not sufficient for census number sel

Re: [Wikidata] Preferred rank -- choices for infoboxes, versus SPARQL

@Markus, James: In my opinion it is better to make the query ask for the most recent population number. People just need to start using time-qualifiers for things like census-report numbers. And the other issue is one of standardized vocabulary and that is always a sourcing problem in my opinion.

Re: [Wikidata] Preferred rank -- choices for infoboxes, versus SPARQL

Hi James, I would immediately agree to the following measures to alleviate your problem: (1) If some instance-of statements are historic (i.e., no longer valid), then one should make the current ones "preferred" and leave the historic ones "normal", just like for, e.g., population numbers. T

Re: [Wikidata] Preferred rank -- choices for infoboxes, versus SPARQL

@James As you mention yourself using ranks is a very limiting approach, and I think that we shouldn't modify the data to help the queries, but try to make the queries more intelligent. - Once confliciting, and time-dependent statements are added to each item, the return values of simple queries wil

Re: [Wikidata] Odd results from wdqs

On 27.11.2015 15:22, Magnus Manske wrote: It was the "absolute terms" problem here ;-) But 3MB uncompressed string data does not seem to be so big in absolute terms, or are you referring to something else (I got this number from the long pages special)? Parsing a 3MB string may need some ext

[Wikidata] Preferred rank -- choices for infoboxes, versus SPARQL

Some items have quite a lot of "instance of" statements, connecting them to quite a few different classes. For example, Frankfurt is currently an instance of seven different classes, https://www.wikidata.org/wiki/Q1794 and Glasgow is currently an instance of five different classes: http

Re: [Wikidata] Odd results from wdqs

It was the "absolute terms" problem here ;-) On Fri, Nov 27, 2015 at 2:12 PM Markus Krötzsch < mar...@semantic-mediawiki.org> wrote: > On 25.11.2015 16:05, Lydia Pintscher wrote: > > On Mon, Nov 23, 2015 at 10:54 PM, Magnus Manske > > wrote: > >> Well, my import code chokes on the last two JSON

Re: [Wikidata] Odd results from wdqs

On 25.11.2015 16:05, Lydia Pintscher wrote: On Mon, Nov 23, 2015 at 10:54 PM, Magnus Manske wrote: Well, my import code chokes on the last two JSON dumps (16th and 23rd). As it fails about half an hour or so in, debugging is ... inefficient. Unless there is something that has changed with the d

[Wikidata] looking for speaker for conference in Vienna

Hey folks :) I am looking for someone who can represent Wikidata here: http://www.oeaw.ac.at/acdh/de/node/396 This is on the 3rd of December so unfortunately short notice. If you are willing and able to talk about Wikidata there let me know and I'll get you in touch with the right people. Cheers