-- Sent from Android --
2015. 8. 30. 오전 7:39에 "James Heald" <j.heald(a)ucl.ac.xn--uk>-n54x791j 작성:
To pick up on a few different comments from this thread:
@revi (Hong, Yongmin)
-- Yes, of course you are correct that it is categories rather than
are the important structure for finding and navigating
images on Commons.
But even if we were to change the status-quo and ban sitelinks from
to Commons galleries (which might not be 100% popular, since
we currently have 87,000 sitelinks to galleries, up by about 3000 in the
last year) -- even if we were to ban sitelinks to galleries, this would
still leave the question of whether Commons categories should be sitelinked
to categories or to articles.
Currently there are 311,000 Commonscats sitelinked to category items on
and 207,000 sitelinked to article items on Wikidata. So the
status-quo is for Commonscats to be sitelinked to category items (and in
the past has been even more so).
The problem is that, the way the software exists at the moment, you can't
both. So if a Commonscat is sitelinked to an article item, that
precludes a Commonscat being sitelinked to a category item, and vice-versa.
At the moment, the expectation is that a Commonscat will be sitelinked to
category item, if possible. Of 323,825 Commonscats that can be
identified with a Wikidata category item, 311,000 are connected by
corresponding sitelinks. So if people are writing scripts or queries to
look for such relationships, they will most likely look for sitelinks.
On the other hand, of 884,439 Commonscats that can be identified with
Wikidata items, only 207,494 (= 23.4%) are connected by
sitelinks -- even if this number has doubled in the last 12 months, the
expectation in the current status quo is that such a connection is more
likely *not* to be represented in a sitelink, by a three-to-one margin.
Instead, links between Commonscats and article-like Wikidata items are
overwhelmingly represented by the P373 property, which at the
moment records 807,776 (= 91.3%) of such identifications.
This is the property that the script
looks up in order to display a link to Reasonator if there is a Wikidata
article-item for a Commonscat.
That does not cover all 7** wikis in WMF wikifarm. (Well yeah, some
projects have wd not enabled, e.g. meta.) TBH I don't like the attempt to
workaround things by js. It should be implemented in the Wikibase to allow
+2~ sitelinks so this long-standing dispute can be buried into the realm of
> To get the best idea of whether there is a
corresponding Wikidata item
and Wikipedia articles for a Commonscat, Commons users should therefore
use wdcat.js -- which is easily activated by adding a line to the
common.js file, such as at
-- because this will pick up four times more connections than currently
> The important think is to establish and
preserve clear expectations, that
software can build against.
> At the moment, with the confusion of
sitelinks of Commonscats to articles
and to categories, there is no guarantee that it is possible to create a
sitelink to an article. On the other hand, it should always be possible to
create a P373 connection. They are the connections that systematically
*can* be made, so it is important to make sure that they systematically
*are* made, to drag up the return rate from the current 91.3% to nearer
> That would be helped by a policy that was
absolutely systematic in
prescribing what should and what should not be sitelinked.
Just leave the status quo until the software is ready. We have been in this
way for years (it was handled this way since I joined WD and Commons
sitelink was added.).
> @ RomaineWiki:
> You say that actively enforcing the
longstanding Wikidata sitelink policy
of only sitelinking Commons categories to category-like items, and Commons
galleries to article-like items would be a plan to
> "demolish the navigational structure
> But it wouldn't change any of the
internal structures on Commons, and
would merely underline the current fact that even now only 23% of
Commonscats are linked to articles by sitelinks, compared to 91% by P373.
> Isn't it better to get Commons users
used to using (and improving) the
wdcat.js script, which uses the P373 property that can always be added,
rather than perpetuating the current muddle of Commonscat <-> article
sitelinks, which are so haphazard ?
Again, doesn't work on other wikis, e.g. enwikinews, kowiki, zhwikivoyage,
(random wikiname here) by default.
> @ Steinsplitter
> As I understand it, the long-term plans for
a new Wikibase structure
specifically for Commons are currently no longer an immediate development
priority; but will presumably start to move forward again sooner or later.
> On the other hand, this discussion was
specifically about sitelinks.
> Here I believe what has driven the Wikidata
side has been the desire to
have a rule that is simple and consistent and predictable, because that is
the foundation needed to develop queries and scripts and tools and
user-interfaces on top of.
> Combining that desideratum with the
technical restriction of only
allowing one sitelink to each item from each wiki and vice-versa, is what
has led to the recommended scheme of linking
> Commons categories <-> category-like items
> Commons galleries <-> article-like items
> with property P373 to handle identification
of Commons categories <-
> This fulfils the requirements of
simplicity, consistency and
> It's not ideal from a user-interface
point of view (or a philosophical
point of view). But so long as the rule is applied consistently, the
limitations it leads to can be worked round with appropriate software
improvements -- eg in the first instance the wdcat.js script.
> But to encourage people to develop and
improve such software, it is
helpful for the above structure to be applied consistently.
> In contrast perpetuating inconsistency and
muddle blurs what is needed,
and works against the stable predictable basis needed to make such software
> All best,
> On 29/08/2015 14:39, Steinsplitter Wiki wrote:
>> Wikidata needs to ask the Commons
Community before doing commons related
>> It is so hard to understand what the
wikidata people like to do with
commons. Tons of text, hard to read. I don't understand what they like to
do, but if this change is affecting commons then commons community
consensus is needed.
>> Date: Fri, 28 Aug 2015 17:34:28 +0200
>> From: romaine.wiki(a)gmail.com
>> To: wikidata(a)lists.wikimedia.org; commons-l(a)lists.wikimedia.org
>> Subject: Re: [Commons-l] [Wikidata] Trends in links from Wikidata items
>> As I wrote before, that thought is too
simple. You only say that a zero
belongs to a zero, and a two belongs to a two, then you only describe the
type of page, but you ignore the subject of a page. That subject matters
much more than the namespace number.
>> Especially Wikinews is a wrong example,
as most categories on Commons do
not have a 1 to 1 relationship with Commons.
> However, articles on Wikipedia do have mostly a 1
on 1 relationship with
categories on Commons.
>> 2015-08-28 17:09 GMT+02:00 Luca
>> 2015-08-28 12:09 GMT+02:00 Romaine Wiki <romaine.wiki(a)gmail.com>om>:
>>> And I agree completely with what
>>>> Wikidata ignores this Commons' fact by trying to enforce
>>>> like this.
>> It's not such a ridiculous rule, if
you think of the rationale behind
>> it: if gallery = ns0 and category =
ns2, linking ns0 <--> ns2 in the
>> same item is IMHO not a rational thing
to do (not even for Wikinews if
>> you ask me, but I'm digressing).
>> So the
*practical* problem that we have to address is the list of
>> links in the left column. We really
don't have any possibilty to
>> exploit P373 in any way, not even with
a .js, to fix this?
>> Wikidata mailing list
>> Commons-l mailing list
>> Commons-l mailing list
> Commons-l mailing list