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]
On Sun, Apr 3, 2016 at 5:06 PM, John Erling Blad <jeblad(a)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(a)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(a)lu.is> wrote:
On Sat, Apr 2, 2016, 4:34 AM Lucie Kaffee
<lucie.kaffee(a)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 uploaded the thesis to commons under a CC-BY-SA license- you can find
it at
https://commons.wikimedia.org/wiki/File:Generating_Article_Placeholders_fro…
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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata