I thought there was already a standard around some "diff" format like DoubleCheck uses. I recall using Wikiloop DoubleCheck which has an interesting interface to expose a portion of an edit for judgement and rollback.
It probably makes sense to pull someone from their team into this conversation as well to explore ideas?

To Reproduce:

1. Create a new Lexeme
2. Lemma: type chevrette
3. Language of Lemma: type cajun and look at dropdown listing
4. Notice that Louisiana French Q3083213 is at the bottom of dropdown list instead of top of list.

In Freebase, we offered word, phrase, and full (exact match). I think the wbsearchentities API could offer something similar, although with a slight cost of indexing.
Besides name we also supported alias{full}. Using alias: matched both name and aliases, using name: matched only on name.

In that case, then just on that wbsearchentities page I think having a single sentence about "userlang" and providing the link to the other page would help like hell for all those users that have asked in the last year alone. As an institution of holding the worlds knowledge in many languages then "userlang" is probably the most important parameter to let users know about especially given the frame of reference here when we are talking about THE Search API that so many eventually land upon using and building around it.

@Gehel Hi Guillaume Isn't the streaming updater work done now by @dcausse ? Is it time for your tuning engineers to revisit some of this or not really?

@dcausse Dunno if this might help but could a simple window help or where you use KeyedProcessFunction on a KeyedStream? If the stream is unkeyed (or initially so), then the other thing might be just finding the patterns in the stream and CEP would help.

• the output of this is a simple event without any data saying: do a diff between rev X and Y, fully delete entity QXYZ, ...

Hi all - My personal opinion and those of a few other experts would be to embrace DRY (Don't Repeat Yourself - or others) and simply allow introduction of W3C standards for Tabular Data:

If it helps or is needed, the query that you can use is here:

@Lydia_Pintscher Oops! You forgot to include the main one also !!! .... Equivalent Property P1628 :-)

Is there anything inherently wrong or technically infeasible or undesirable, if an id used 2 letters? ES45 versus E45 ?

Thanks, updated ticket.

@dcausse Yes, I mean running a full text search. "simple search" is a term used by Blazegraph sometimes. Fulltext searches are cheap when you index terms in multiple ways. Why would you not want to index terms in multiple ways? Freebase was able to leverage this quite easily with Lucene/Solr indexes and provided great results on its search box on each character typed. Are you hurting for RAM to store the cached inverted indexes or something else with the infra? My quick calculations on 1 simple index in memory for all the terms (not just label/alias) in Wikidata, currently stats say 78 billion x 10 bytes per term = 78 gigs. Does Wikidata not have hardware to support multiple indexes? 1TB RAM (16x 64GB)

No problem @Tgr

What slows me down is not having an efficient quick way to filter properties that don't include " ID" (non-authority properties), in various Property explorer tools such as the excellent https://tools.wmflabs.org/prop-explorer/
Perhaps other Property explorer tools have a quick filter mechanism for this? I tried a simple regex in the Label column filter, but it doesn't work. https://github.com/stevenliuyi/wikidata-prop-explorer/issues/1

TODO: Just wanted to highlight that once decisions are made... please ensure to update the Glossary item ! Currently it reads:

@dbarratt in the Wikibase ontology I could not find those properties in the OWL document returned. Sorry, I'm getting caught up with your schema layouts as fast as I can :-) I expected my parser to retrieve information about their description, range, domain. I do see the class "Statement" however.

Something is amiss with these...not found.