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 galleries that 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 Wikidata items 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 Wikidata, 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 have 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 a 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 article-like 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 currently 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 https://commons.wikimedia.org/wiki/User:Jheald/wdcat.js looks up in order to display a link to Reasonator if there is a Wikidata article-item for a Commonscat.
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 https://commons.wikimedia.org/wiki/User:Jheald/common.js -- because this will pick up four times more connections than currently exist as sitelinks.
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 100%.
That would be helped by a policy that was absolutely systematic in prescribing what should and what should not be sitelinked.
@ 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 of Commons".
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 ?
@ 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 <-> article-like items.
This fulfils the requirements of simplicity, consistency and predictability.
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 work.
All best, James.
On 29/08/2015 14:39, Steinsplitter Wiki wrote:
Wikidata needs to ask the Commons Community before doing commons related changes.
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@gmail.com To: wikidata@lists.wikimedia.org; commons-l@lists.wikimedia.org Subject: Re: [Commons-l] [Wikidata] Trends in links from Wikidata items to Commons
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.
Romaine
2015-08-28 17:09 GMT+02:00 Luca Martinelli martinelliluca@gmail.com: 2015-08-28 12:09 GMT+02:00 Romaine Wiki romaine.wiki@gmail.com:
And I agree completely with what Revi says:
Wikidata ignores this Commons' fact by trying to enforce ridiculous rules
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?
L.
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Replies inline.
-- revi https://revi.me -- Sent from Android -- 2015. 8. 30. 오전 7:39에 "James Heald" j.heald@ucl.ac.uk님이 작성:
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
galleries that 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
Wikidata items 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
Wikidata, 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
have 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
a 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
article-like 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
currently 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 https://commons.wikimedia.org/wiki/User:Jheald/wdcat.js 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 historical discussions.
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
https://commons.wikimedia.org/wiki/User:Jheald/common.js -- because this will pick up four times more connections than currently
exist as sitelinks.
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 100%.
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 of Commons".
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 <->
article-like items.
This fulfils the requirements of simplicity, consistency and
predictability.
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 work.
All best, James.
On 29/08/2015 14:39, Steinsplitter Wiki wrote:
Wikidata needs to ask the Commons Community before doing commons related
changes.
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@gmail.com To: wikidata@lists.wikimedia.org; commons-l@lists.wikimedia.org Subject: Re: [Commons-l] [Wikidata] Trends in links from Wikidata items
to Commons
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.
Romaine
2015-08-28 17:09 GMT+02:00 Luca Martinelli martinelliluca@gmail.com: 2015-08-28 12:09 GMT+02:00 Romaine Wiki romaine.wiki@gmail.com:
And I agree completely with what Revi says:
Wikidata ignores this Commons' fact by trying to enforce ridiculous
rules
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?
L.
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Il 30/ago/2015 05:30, "Yongmin Hong" lists@revi.pe.kr ha scritto:
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 historical discussions.
Am I the only one that thinks that jheald's .js is a temporary solution? Am I the only one that actually appreciate his attempt at solving a *practical* problem by providing a *practical* solution, while we wait for a long-term, stable solution?
I'd like to remember everyone, me included, that the Wikidata team has lots of irons into fire at the moment, and that they cannot take them all out at the same moment. They're good, but not apt to miracles - as none of us is, AFAIK. So, unless someone has the means to actually solve this problem on the technical side, we'll have to wait and, while we're waiting, put up something that will reduce the inconvenience in the meantime.
Since I don't have too much connection here, I'll reserve for another post a couple of examples of why making 2+ sitelinks for item available it's just a terrible, terrible idea, and I'll go straight to the point: why don't we make the .js a part of the common.js and make it work properly until things are fixed?
L.
Luca Martinelli, 30/08/2015 12:03:
Am I the only one that thinks that jheald's .js is a temporary solution? Am I the only one that actually appreciate his attempt at solving a *practical* problem by providing a *practical* solution,
It might be a practical solution, but I don't understand what it solves: what's the practical problem? Quoting from the project chat, the problem to me seems this: «2.4 millions categories are not connected to corresponding Wikipedia articles. [...] — Ivan A. Krestinin (talk) 20:22, 18 August 2015 (UTC)».
Nemo
the problem I see is that commons will always have more categories than wikipedia can have articles take fences, commons has wooden fences this broken into many cats including wooden fences in a country, this then grows and then gets broken into sub national entities while the number of articles on wikipedia remains at one commons now has 196 country articles with anything between 5 and 50 sub national entities, then some idiot paints his fence now we have wooden fences by colour in a little over 3000 pantone colours....
What I'm seeing here is solution that has the horse pushing the cart problem lies not in linking commons cats to wikipedia articles wikidata but in ensuring wikidata articles are linked to the full range of categories available on commons and that those links can be easily adjusted as necessary
On 30 August 2015 at 18:42, Federico Leva (Nemo) nemowiki@gmail.com wrote:
Luca Martinelli, 30/08/2015 12:03:
Am I the only one that thinks that jheald's .js is a temporary solution? Am I the only one that actually appreciate his attempt at solving a *practical* problem by providing a *practical* solution,
It might be a practical solution, but I don't understand what it solves: what's the practical problem? Quoting from the project chat, the problem to me seems this: «2.4 millions categories are not connected to corresponding Wikipedia articles. [...] — Ivan A. Krestinin (talk) 20:22, 18 August 2015 (UTC)».
Nemo
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Overwriting the commons category system needs large consensus. And i don't think that commons community agree with such a change.
So i ask again the wikidata people, please start a RRF on commons or respect our categorization schema. Commons has a own community with active users. It is not okay that a other project is deciding commons stuff whiteout asking commons.
I suggest to move this discussion to COM:VP.
Date: Sun, 30 Aug 2015 22:51:07 +0800 From: gnangarra@gmail.com To: commons-l@lists.wikimedia.org CC: wikidata@lists.wikimedia.org Subject: Re: [Commons-l] [Wikidata] Trends in links from Wikidata items to Commons
the problem I see is that commons will always have more categories than wikipedia can have articles take fences, commons has wooden fences this broken into many cats including wooden fences in a country, this then grows and then gets broken into sub national entities while the number of articles on wikipedia remains at one commons now has 196 country articles with anything between 5 and 50 sub national entities, then some idiot paints his fence now we have wooden fences by colour in a little over 3000 pantone colours....
What I'm seeing here is solution that has the horse pushing the cart problem lies not in linking commons cats to wikipedia articles wikidata but in ensuring wikidata articles are linked to the full range of categories available on commons and that those links can be easily adjusted as necessary On 30 August 2015 at 18:42, Federico Leva (Nemo) nemowiki@gmail.com wrote: Luca Martinelli, 30/08/2015 12:03:
Am I the only one that thinks that jheald's .js is a temporary solution?
Am I the only one that actually appreciate his attempt at solving a
*practical* problem by providing a *practical* solution,
It might be a practical solution, but I don't understand what it solves: what's the practical problem?
Quoting from the project chat, the problem to me seems this: «2.4 millions categories are not connected to corresponding Wikipedia articles. [...] — Ivan A. Krestinin (talk) 20:22, 18 August 2015 (UTC)».
Nemo
_______________________________________________
Commons-l mailing list
Commons-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/commons-l
We will be moving to Commonsdata which will let us do queries to generate millions of category like groups on the fly. There is little point in messing with commons categories before then.
Joe
On Mon, 31 Aug 2015 09:54 Steinsplitter Wiki steinsplitter-wiki@live.com wrote:
Overwriting the commons category system needs large consensus. And i don't think that commons community agree with such a change.
So i ask again the wikidata people, please start a RRF on commons or respect our categorization schema. Commons has a own community with active users. It is not okay that a other project is deciding commons stuff whiteout asking commons.
I suggest to move this discussion to COM:VP.
Date: Sun, 30 Aug 2015 22:51:07 +0800 From: gnangarra@gmail.com To: commons-l@lists.wikimedia.org CC: wikidata@lists.wikimedia.org
Subject: Re: [Commons-l] [Wikidata] Trends in links from Wikidata items to Commons
the problem I see is that commons will always have more categories than wikipedia can have articles take fences, commons has wooden fences this broken into many cats including wooden fences in a country, this then grows and then gets broken into sub national entities while the number of articles on wikipedia remains at one commons now has 196 country articles with anything between 5 and 50 sub national entities, then some idiot paints his fence now we have wooden fences by colour in a little over 3000 pantone colours....
What I'm seeing here is solution that has the horse pushing the cart problem lies not in linking commons cats to wikipedia articles wikidata but in ensuring wikidata articles are linked to the full range of categories available on commons and that those links can be easily adjusted as necessary
On 30 August 2015 at 18:42, Federico Leva (Nemo) nemowiki@gmail.com wrote:
Luca Martinelli, 30/08/2015 12:03:
Am I the only one that thinks that jheald's .js is a temporary solution? Am I the only one that actually appreciate his attempt at solving a *practical* problem by providing a *practical* solution,
It might be a practical solution, but I don't understand what it solves: what's the practical problem? Quoting from the project chat, the problem to me seems this: «2.4 millions categories are not connected to corresponding Wikipedia articles. [...] — Ivan A. Krestinin (talk) 20:22, 18 August 2015 (UTC)».
Nemo
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
-- GN. Vice President Wikimedia Australia WMAU: http://www.wikimedia.org.au/wiki/User:Gnangarra Photo Gallery: http://gnangarra.redbubble.com
_______________________________________________ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l _______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Currently there are 311,000 Commonscats sitelinked to category items on
Wikidata, 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).
Why are you using statistics in a false way to try to get your point? 40% of the sitelinks are to articles on Wikipedia, 207 thousand, that is a gigantic number. So the status quo is that both are acceptable. Please stop with telling nonsense.
But it wouldn't change any of the internal structures on Commons
Are you not understanding the situation or just ignoring the key points? If you do not take the situation serious, you disqualify yourself.
For Commons is linking to Wikipedia an essential infrastructure. I was speaking about that, and it is completely unacceptable to demolish that.
If you do not want to help actually to improve the situation, including for Commons, go do something else. You are not helping to improve, but are distracting us from finding a solution that does not demolish essential infrastructure.
I have clearly described the situation: as long if there is no software improvement for Commons, the status quo that both articles and categories are used as sitelink for Commons will remain the situation.
Romaine
2015-08-30 0:39 GMT+02:00 James Heald j.heald@ucl.ac.uk:
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 galleries that 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 Wikidata items 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 Wikidata, 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 have 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 a 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 article-like 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 currently 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 https://commons.wikimedia.org/wiki/User:Jheald/wdcat.js looks up in order to display a link to Reasonator if there is a Wikidata article-item for a Commonscat.
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 https://commons.wikimedia.org/wiki/User:Jheald/common.js -- because this will pick up four times more connections than currently exist as sitelinks.
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 100%.
That would be helped by a policy that was absolutely systematic in prescribing what should and what should not be sitelinked.
@ 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 of Commons".
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 ?
@ 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 <-> article-like items.
This fulfils the requirements of simplicity, consistency and predictability.
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 work.
All best, James.
On 29/08/2015 14:39, Steinsplitter Wiki wrote:
Wikidata needs to ask the Commons Community before doing commons related changes.
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@gmail.com To: wikidata@lists.wikimedia.org; commons-l@lists.wikimedia.org Subject: Re: [Commons-l] [Wikidata] Trends in links from Wikidata items to Commons
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.
Romaine
2015-08-28 17:09 GMT+02:00 Luca Martinelli martinelliluca@gmail.com: 2015-08-28 12:09 GMT+02:00 Romaine Wiki romaine.wiki@gmail.com:
And I agree completely with what Revi says:
Wikidata ignores this Commons' fact by trying to enforce ridiculous rules
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?
L.
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l