> Ordering of statement groups

The solution described (?) seems to me as "dev-ish" way to do this, and I think it is wrong. The grouping is something that should be done dynamically, as it depends both on the item itself (ie the knowledge base), its class hierarchy (ie interpretation of the knowledge base, often part of the knowledge base), our communicative goal (the overall context of the communication), the discourse (usually we drop this, as we don't maintain state), and the user model (which changes through a wp-article). This 4-tuple is pretty well-known in Natural Language Generation, but the implications for reuse of Wikidata statements in Wikipedia is mostly neglected. (That is not something Lucie should discuss in a bachelor thesis, but it is extremely important if the goal for Wikidata is actual reuse on Wikipedia)

That said; I tried to figure out whats the idea, and also read the RfC (Statement group ordering [1]), but actually I don't know whats planned here. I think I know it, but most probably I don't. The statement group ordering is a on-wiki list of ordered groups? How do you create those groups? What is the implications on those groups? Does it has implications for other visualizations? What if groups should follow the type of the item? It seems like this describe a system where "one size fits all - or make it youself".

And not to forget, where is the discussion? An RfC with no discussion?

[1] https://www.mediawiki.org/wiki/Requests_for_comment/Statement_group_ordering

On Sun, Apr 3, 2016 at 5:06 PM, John Erling Blad <jeblad@gmail.com> wrote:

> Red links are used frequently in Wikipedia to indicate an article which is does
> not yet exist, but should. Today it leads the user to an empty create article page.
> In the future it should instead bring them to an ArticlePlaceholder, offering the
> option of creating an article. This is part of the topic of smart red links, which is
> discussed in the section 8.1: Smart red links

It should be interesting to hear if someone have an idea how this might work. There are some attempts on this at nowiki, none of them seems to work in all cases.

Note that "Extension:ArticlePlaceholder/Smart red links" doesn't really solve the problem for existing redlinks, it solves the association problem when the user tries to resolve the redlink. That is one step further down the line, or more like solving the redlinks for a disambiguation page. ("I know there is a page like this, named like so, on that specific project.")

Note also that an item is not necessarily described on any project, and that creating an item on Wikidata can be outside the editors scope or even very difficult. Often we have a name of some "thing", but we only have a sketchy idea about the thing itself. Check out https://www.wikidata.org/wiki/Q12011301 for an example.

It seems like a lot of what are done so far on redlinks is an attempt to make pink-ish links with _some_information_, while the problem is that redlinks have _no_information_. The core reason why we have redlinks is that we lacks manpower to avoid them, and because of that we can't just add "some information". It is not a problem of what we need first, hens or eggs, as we have none of them.

On Sun, Apr 3, 2016 at 4:27 PM, John Erling Blad <jeblad@gmail.com> wrote:
Just read through the doc, and found some important points. I post each one in a separate mail.

> Since it is hard to decide which content is actually notable, the items appear-
> ing in the search should be limited to the ones having at least one statements
> and two sitelinks to the same project (like Wikipedia or Wikivoyage).

This is a good baseline, but figuring out what is notable locally is a bit more involved. A language is used in a local area, and within that area some items are more important just because they reside within the area. This is quite noticeable in the differences between nnwiki and nowiki which both basically covers "Norway". Also items that somehow relates to the local area or language is more noticeable than those outside those areas. By traversing upwords in the claims using the "part of" property it is possible to build a priority on the area involved. It is possible to traverse "nationality" and a few other properties.

Things directly noticeable like an area enclosed in an area using the language is somewhat easy to identify, but things that are noticeable by association with another noticeable thing is not. Like a Danish slave ship operated by a Norwegian firm, the ship is thus noticeable in nowiki. I would say that all things linked as an item from other noticeable things should be included. Some would perhaps say that "items with second order relevance should be included".


On Sat, Apr 2, 2016 at 11:09 PM, Luis Villa <luis@lu.is> wrote:
On Sat, Apr 2, 2016, 4:34 AM Lucie Kaffee <lucie.kaffee@wikimedia.de> wrote:
I wrote my Bachelor's thesis on "Generating Article Placeholders from Wikidata for Wikipedia: Increasing Access to Free and Open Knowledge". The thesis summarizes a lot of the work done on the ArticlePlaceholder extension ( https://www.mediawiki.org/wiki/Extension:ArticlePlaceholder )
I continue working on the extension and aim to deploy it to the first Wikipedias, that are interested, in the next months. 

I am happy to answer questions related to the extension!

Great work on something that I believe has a lot of promise - thanks! I really think this approach has a lot of promise to help take back some readership from Google, and potentially in the long-run drive more new editors as well. (I know that was part of the theory of LSJbot, though I don't know if anyone has actually a/b tested that.)

I was somewhat surprised to not see data collection discussed in Section 8.10 - are there plans to do that? I would have expected to see a/b testing discussed as part of the deployment methodology, so that it could be compared both to the current baseline and also to similar approaches (like the ones you survey in Section 3).

Thanks again for the hard work here-

Luis

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