JanZerebecki added a comment. This is real data. If the system can not cope with data changes of the discussed scope, i have the suspicion it woun't be able to cope with normal day to day changes in the data.
If optimization for specific types of queries on specific properties is necessary that would constrain the systems usefulness. We should try to avoid that if possible. There are quite a few properties where it is correct to have no preferred and 10 normal ranked statements (examples from Obama: educated at, award received, website account on, described by source). I would like to know if Titan is capable to compute cases like this in a generic way and still be fast enough. If it is, the correctly ranked data should result in faster responses. Then wouldn't the current data be enough for evaluation? To write queries that correctly deal with multiple possibilities and also if we were to better optimize the data for answering a specific query their use needs to be more specific. E.g. for the cities with the biggest population there are multiple ways once the date qualifier is exhausted to get the latest number: a) More accurately represent possibilities (each top spot can have multiple possibilities and cities can appear on multiple spots). b) Higher number wins. c) Lower number wins. Anyway it seems to me that such a query is not an interactive use case. It is like something to be evaluated as CPU is available in a batch way (think Hadoop) and the result saved for viewing, probably updating it at some point in the same way. If queries like that are not fast enough to be done in an interactive way, we need better, more specific use cases for interactive queries. TASK DETAIL https://phabricator.wikimedia.org/T76373 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign <username>. To: Smalyshev, JanZerebecki Cc: Smalyshev, Manybubbles, GWicke, JanZerebecki, aude, Lydia_Pintscher, jkroll, Wikidata-bugs, daniel _______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
