Re: [Wikidata] Trends in links from Wikidata items to Commons

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [Wikidata] Trends in links from Wikidata items to Commons

Romaine Wiki-2
I think this subject should also be discussed on the Commons mailing list, as this plan is to demolish the navigational structure of Commons.

2015-08-27 15:03 GMT+02:00 Romaine Wiki <[hidden email]>:
No we have not a clear policy on only linking sitelinks to categories if the item itself is about a category. So not let's not break that.

You suggest to break down almost the complete navigational structure Commons has in relationship with Wikipedia, and makes it possible to find articles that are about the same subject as the category. Without it becomes almost impossible to identify a category on Commons to be related to an article in Wikipedia.
Sorry, but your proposal is insane and making the navigational situation a thousand times worse. And does it make anything better? No, totally not. Only the opposite: worse.

Wikidata is currently heavily used to connect categories on Commons to articles on Wikipedia. This so that interwikilinks are shown on the category on Commons to the related Wikipedia article. This for navigational purposes but also to uniquely identify categories on Commons to articles on Wikipedia and items on Wikidata.

How nice Commons galleries are giving an overview, they are crap in speaking of navigational purposes. For every subject a category on Commons is created and used and the Commons categories form the backbone to media categories.

It has been pointed out for a long time that the linking situation on Commons is problematic and this is a software issue, not a user side issue. This consists out of:
* There can only be added one sitelink to an item.
* If no sitelink added (but only added as property), a Commons category can't show the interwikilinks.
* If a category and an article on Wikipedia/etc exist for a subject, only one of them can be shown on the Commons category.

The annoying part is that some large wikis, especially the English Wikipedia, creates too many categories that are not created on other Wikipedias. This causes that categories on Commons are only linked to a category on Wikipedia, which is useless for most other wikis and on Commons we miss an interwikilink to the related article.

A gallery on Commons is a great way as alternative to show images, but is not suitable for navigational purposes, as that requires a much higher coverage and being a backbone everything relies on. On Commons only categories have that function. A counter proposal makes more sense: no Commons galleries as sitelinks any more and having Commons galleries only as property added.

But this only solves a part of the problem: on Commons I would like to see somehow that both the related category as the related article are shown. Example: on the Commons category for a specific country both the country category on Wikipedia is linked as the article on Wikipedia is linked.

Something I have been wondering about for a long time is why there are 2 places on an item where a Commonscat is added. I understand the development and technical behind it, but this should not be needed.

So the developers of Wikidata should try to find a way to show both groups of interwikilinks on categories on Commons.

As long as this is not resolved in software, this problem of 2 items both strongly related to a Commons category keeps an issue.

Romaine





2015-08-27 11:29 GMT+02:00 James Heald <[hidden email]>:
A few days ago I made the following post to Project Chat, looking at how people are linking from Wikidata items to Commons categories and galleries compared to a year ago, that some people on the list may have seen, which has now been archived:

https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2015/08#Trends_in_links_from_items_to_Commons


A couple of headlines:

* Category <-> commonscat identifications :

** There was a net increase of 61,784 Commons categories that can now be identified with category-like items, to 323,825 Commons categories in all

**  96.4% of category <-> commonscat identifications (312,266 items) now have sitelinks.  This represents a rise in sitelinks (60,463 items) amounting to 97.8% of the increase in identifications

**  80.0% of category <-> commonscat identifications (259,164 items) now have P373 statements.  This represents a rise in P373 statements (8,774 items) amounting to 14.2% of the increase in identifications


*  Article <-> commonscat identifications :

** There was a net increase of 176,382 Commons categories that can now be identified with article-like items, to 884,439 Commons categories in all

** 23.4% of article <-> commonscat identifications (207,494 items) now have (deprecated) sitelinks. This represents a rise in sitelinks (112,595 items) amounting to 63.8% of the increase in identifications.

** 91.3% of article <-> commonscat identifications (807,776 items) now have P373 statements. This represents a rise in P373 statements (110,727 items) amounting to 62.8% of the increase in identifications


*  In addition, a recent RfC showed considerable confusion as to what actually was the current operational Wikidata policy on sitelinks to Commons:

https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Category_commons_P373_and_%22Other_sites%22


In view of the trends above; and the need for predictability and consistency for queries and templates and scripts to depend on; and particularly in view of the apparent confusion as to what the operational policy currently actually is, can I suggest that the time has come for a bot to monitor all new sitelinks to Commons categories,
*  adding a corresponding P373 statement if there is not one already, and
*  removing the sitelink if it is from an article-like item to a commonscat.


I believe we have clear policy on only sitelinking commons categories to category-like items, and commons galleries to article-like items; but there is currently confusion and unpredictability being caused because these relationships are not being enforced -- breaking scripts and queries.

It's time to fix this.


All best,

  James.


_______________________________________________
Wikidata mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikidata



_______________________________________________
Commons-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikidata] Trends in links from Wikidata items to Commons

Romaine Wiki-2
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 <[hidden email]>:
2015-08-28 12:09 GMT+02:00 Romaine Wiki <[hidden email]>:
> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikidata


_______________________________________________
Commons-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikidata] Trends in links from Wikidata items to Commons

Reguyla
In reply to this post by Romaine Wiki-2
This is one reason I create the pahbricator request for Commons to have its own Site box rather than fall under "Other wiki's". That would allow us to link an item to its corresponding Gallery, Category, Creator or whatever. Right now we can only like to Commons category via the Other Wiki's and although we can link Galleries, Creator and the like as data items, they are not "linked" as site links.
 
Reguyla

On Fri, Aug 28, 2015 at 11:28 AM, Romaine Wiki <[hidden email]> wrote:
I think this subject should also be discussed on the Commons mailing list, as this plan is to demolish the navigational structure of Commons.

2015-08-27 15:03 GMT+02:00 Romaine Wiki <[hidden email]>:
No we have not a clear policy on only linking sitelinks to categories if the item itself is about a category. So not let's not break that.

You suggest to break down almost the complete navigational structure Commons has in relationship with Wikipedia, and makes it possible to find articles that are about the same subject as the category. Without it becomes almost impossible to identify a category on Commons to be related to an article in Wikipedia.
Sorry, but your proposal is insane and making the navigational situation a thousand times worse. And does it make anything better? No, totally not. Only the opposite: worse.

Wikidata is currently heavily used to connect categories on Commons to articles on Wikipedia. This so that interwikilinks are shown on the category on Commons to the related Wikipedia article. This for navigational purposes but also to uniquely identify categories on Commons to articles on Wikipedia and items on Wikidata.

How nice Commons galleries are giving an overview, they are crap in speaking of navigational purposes. For every subject a category on Commons is created and used and the Commons categories form the backbone to media categories.

It has been pointed out for a long time that the linking situation on Commons is problematic and this is a software issue, not a user side issue. This consists out of:
* There can only be added one sitelink to an item.
* If no sitelink added (but only added as property), a Commons category can't show the interwikilinks.
* If a category and an article on Wikipedia/etc exist for a subject, only one of them can be shown on the Commons category.

The annoying part is that some large wikis, especially the English Wikipedia, creates too many categories that are not created on other Wikipedias. This causes that categories on Commons are only linked to a category on Wikipedia, which is useless for most other wikis and on Commons we miss an interwikilink to the related article.

A gallery on Commons is a great way as alternative to show images, but is not suitable for navigational purposes, as that requires a much higher coverage and being a backbone everything relies on. On Commons only categories have that function. A counter proposal makes more sense: no Commons galleries as sitelinks any more and having Commons galleries only as property added.

But this only solves a part of the problem: on Commons I would like to see somehow that both the related category as the related article are shown. Example: on the Commons category for a specific country both the country category on Wikipedia is linked as the article on Wikipedia is linked.

Something I have been wondering about for a long time is why there are 2 places on an item where a Commonscat is added. I understand the development and technical behind it, but this should not be needed.

So the developers of Wikidata should try to find a way to show both groups of interwikilinks on categories on Commons.

As long as this is not resolved in software, this problem of 2 items both strongly related to a Commons category keeps an issue.

Romaine





2015-08-27 11:29 GMT+02:00 James Heald <[hidden email]>:
A few days ago I made the following post to Project Chat, looking at how people are linking from Wikidata items to Commons categories and galleries compared to a year ago, that some people on the list may have seen, which has now been archived:

https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2015/08#Trends_in_links_from_items_to_Commons


A couple of headlines:

* Category <-> commonscat identifications :

** There was a net increase of 61,784 Commons categories that can now be identified with category-like items, to 323,825 Commons categories in all

**  96.4% of category <-> commonscat identifications (312,266 items) now have sitelinks.  This represents a rise in sitelinks (60,463 items) amounting to 97.8% of the increase in identifications

**  80.0% of category <-> commonscat identifications (259,164 items) now have P373 statements.  This represents a rise in P373 statements (8,774 items) amounting to 14.2% of the increase in identifications


*  Article <-> commonscat identifications :

** There was a net increase of 176,382 Commons categories that can now be identified with article-like items, to 884,439 Commons categories in all

** 23.4% of article <-> commonscat identifications (207,494 items) now have (deprecated) sitelinks. This represents a rise in sitelinks (112,595 items) amounting to 63.8% of the increase in identifications.

** 91.3% of article <-> commonscat identifications (807,776 items) now have P373 statements. This represents a rise in P373 statements (110,727 items) amounting to 62.8% of the increase in identifications


*  In addition, a recent RfC showed considerable confusion as to what actually was the current operational Wikidata policy on sitelinks to Commons:

https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Category_commons_P373_and_%22Other_sites%22


In view of the trends above; and the need for predictability and consistency for queries and templates and scripts to depend on; and particularly in view of the apparent confusion as to what the operational policy currently actually is, can I suggest that the time has come for a bot to monitor all new sitelinks to Commons categories,
*  adding a corresponding P373 statement if there is not one already, and
*  removing the sitelink if it is from an article-like item to a commonscat.


I believe we have clear policy on only sitelinking commons categories to category-like items, and commons galleries to article-like items; but there is currently confusion and unpredictability being caused because these relationships are not being enforced -- breaking scripts and queries.

It's time to fix this.


All best,

  James.


_______________________________________________
Wikidata mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikidata



_______________________________________________
Commons-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l



_______________________________________________
Commons-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikidata] Trends in links from Wikidata items to Commons

Steinsplitter Wiki
In reply to this post by Romaine Wiki-2
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: [hidden email]
To: [hidden email]; [hidden email]
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 <[hidden email]>:
2015-08-28 12:09 GMT+02:00 Romaine Wiki <[hidden email]>:
> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikidata


_______________________________________________ Commons-l mailing list [hidden email] https://lists.wikimedia.org/mailman/listinfo/commons-l

_______________________________________________
Commons-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikidata] Trends in links from Wikidata items to Commons

James Heald
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: [hidden email]
> To: [hidden email]; [hidden email]
> 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 <[hidden email]>:
> 2015-08-28 12:09 GMT+02:00 Romaine Wiki <[hidden email]>:
>
>> 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
>
> [hidden email]
>
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
>
>
>
> _______________________________________________
> Commons-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/commons-l   
>
>
>
> _______________________________________________
> Commons-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/commons-l
>


_______________________________________________
Commons-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikidata] Trends in links from Wikidata items to Commons

Amazon Sec. Team messages-noreply@amazon.com

Replies inline.

--
revi
https://revi.me
-- Sent from Android --
2015. 8. 30. 오전 7:39에 "James Heald" <[hidden email]>님이 작성:
>
> 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: [hidden email]
>> To: [hidden email]; [hidden email]
>> 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 <[hidden email]>:
>> 2015-08-28 12:09 GMT+02:00 Romaine Wiki <[hidden email]>:
>>
>>> 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
>>
>> [hidden email]
>>
>> https://lists.wikimedia.org/mailman/listinfo/wikidata
>>
>>
>>
>>
>> _______________________________________________
>> Commons-l mailing list
>> [hidden email]
>> https://lists.wikimedia.org/mailman/listinfo/commons-l                                 
>>
>>
>>
>> _______________________________________________
>> Commons-l mailing list
>> [hidden email]
>> https://lists.wikimedia.org/mailman/listinfo/commons-l
>>
>
>
> _______________________________________________
> Commons-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/commons-l


_______________________________________________
Commons-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikidata] Trends in links from Wikidata items to Commons

Yann Forget-3
In reply to this post by Steinsplitter Wiki
Hi, I can only say that I agree 100% with Steinsplitter.

Yann

2015-08-29 15:39 GMT+02:00 Steinsplitter Wiki <[hidden email]>:
> 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.

_______________________________________________
Commons-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikidata] Trends in links from Wikidata items to Commons

Federico Leva (Nemo)
In reply to this post by Amazon Sec. Team messages-noreply@amazon.com
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikidata] Trends in links from Wikidata items to Commons

Gnangarra
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) <[hidden email]> 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
[hidden email]
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikidata] Trends in links from Wikidata items to Commons

Steinsplitter Wiki
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: [hidden email]
To: [hidden email]
CC: [hidden email]
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) <[hidden email]> 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
[hidden email]
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 [hidden email] https://lists.wikimedia.org/mailman/listinfo/commons-l

_______________________________________________
Commons-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikidata] Trends in links from Wikidata items to Commons

Gerard Meijssen-3
In reply to this post by Gnangarra
Hoi.
The problem with Commons is that its categories will be largely redundant once Wikidata type technology will replace them, It will be just a question of having a query for the result that you want.. If you want to have fences in mauve, by all means, query for it but there may be the surprise that there are none.

Creating items for categories for Commons is imho an exercise in futility.. What is the point after all ? Having those categories may mean that we have a clue what queries are of interest..So when people add those categories, it is current best practice.
Thanks,
     GerardM

On 30 August 2015 at 16:51, Gnangarra <[hidden email]> wrote:
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) <[hidden email]> 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
[hidden email]
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l



_______________________________________________
Commons-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikidata] Trends in links from Wikidata items to Commons

Steinsplitter Wiki
>>The problem with Commons is that its categories will be largely redundant once Wikidata type technology will replace them

Can you elaborate please? What is replacing commons category system?

...


From: [hidden email]
Date: Sun, 30 Aug 2015 20:30:36 +0200
To: [hidden email]
Subject: Re: [Commons-l] [Wikidata] Trends in links from Wikidata items to Commons

Hoi.
The problem with Commons is that its categories will be largely redundant once Wikidata type technology will replace them, It will be just a question of having a query for the result that you want.. If you want to have fences in mauve, by all means, query for it but there may be the surprise that there are none.

Creating items for categories for Commons is imho an exercise in futility.. What is the point after all ? Having those categories may mean that we have a clue what queries are of interest..So when people add those categories, it is current best practice.
Thanks,
     GerardM

On 30 August 2015 at 16:51, Gnangarra <[hidden email]> wrote:
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) <[hidden email]> 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
[hidden email]
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l



_______________________________________________ Commons-l mailing list [hidden email] https://lists.wikimedia.org/mailman/listinfo/commons-l

_______________________________________________
Commons-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikidata] Trends in links from Wikidata items to Commons

Gerard Meijssen-3
Hoi,
A category includes images that have shared characteristics.  The problem with categories is that they are error prone, mistakes are made or they are just not added or understood. A category like "Frisian stallions" has obviously stallions of the Frisian breed in them.  When an image is known to have a "Friese stamboekhengst" in Dutch, you do not need to add a text for "Frisian stallion". Because one is the translation of the other. You can search for all the paintings by 文森·梵谷 and tind the same paintings I would when I seek them for Vincent van Gogh.

There is nothing wrong with having categories at this time. It is just that once we add statements, the same information will be available in every other language. We cannot do it now. The whole current issue with Wikidata is not that relevant as it will change when development time is put into place and have Wikidata type annotations and queries in a way that is not only but also English.
Thanks,
      GerardM

On 30 August 2015 at 20:37, Steinsplitter Wiki <[hidden email]> wrote:
>>The problem with Commons is that its categories will be largely redundant once Wikidata type technology will replace them

Can you elaborate please? What is replacing commons category system?

...


From: [hidden email]
Date: Sun, 30 Aug 2015 20:30:36 +0200
To: [hidden email]
Subject: Re: [Commons-l] [Wikidata] Trends in links from Wikidata items to Commons

Hoi.
The problem with Commons is that its categories will be largely redundant once Wikidata type technology will replace them, It will be just a question of having a query for the result that you want.. If you want to have fences in mauve, by all means, query for it but there may be the surprise that there are none.

Creating items for categories for Commons is imho an exercise in futility.. What is the point after all ? Having those categories may mean that we have a clue what queries are of interest..So when people add those categories, it is current best practice.
Thanks,
     GerardM

On 30 August 2015 at 16:51, Gnangarra <[hidden email]> wrote:
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) <[hidden email]> 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
[hidden email]
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l



_______________________________________________ Commons-l mailing list [hidden email] https://lists.wikimedia.org/mailman/listinfo/commons-l

_______________________________________________
Commons-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l



_______________________________________________
Commons-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikidata] Trends in links from Wikidata items to Commons

Michael Peel-2
In reply to this post by Reguyla

> On 28 Aug 2015, at 18:40, Reguyla <[hidden email]> wrote:
>
> This is one reason I create the pahbricator request for Commons to have its own Site box rather than fall under "Other wiki's". That would allow us to link an item to its corresponding Gallery, Category, Creator or whatever. Right now we can only like to Commons category via the Other Wiki's and although we can link Galleries, Creator and the like as data items, they are not "linked" as site links.

This would be very useful - I think this would be a good way forward that would avoid the whole 'page vs. category' debate. The Phabricator ticket is at:
https://phabricator.wikimedia.org/T102417

Thanks,
Mike
_______________________________________________
Commons-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikidata] Trends in links from Wikidata items to Commons

Daniel Schwen-2
Hi all,
before we write off the category system (as
living-in-the-future-Gerard seems to do ;-) we should probably rather
think about killing galleries. All of them. Completely. Galleries
require a considerable maintenance overhead, and I would argue that
that work is better spent on categorizing our content. We could
replace galleries by allowing select images to retain high level
categories (for example through a template so the don't accidentally
get diffused down the tree). The captions in galleries are just an
i18n nightmare and a data duplication of the description texts.
This does not entirely solve the problem of still having the Creator
namespace, but if were up to me, we'd _not_ interwikilink there, but
rather to the "Works by .." category, because that is what I think
people expect to find on commons: Images
Cheers,
Daniel

On Sun, Aug 30, 2015 at 2:36 PM, Michael Peel <[hidden email]> wrote:

>
>> On 28 Aug 2015, at 18:40, Reguyla <[hidden email]> wrote:
>>
>> This is one reason I create the pahbricator request for Commons to have its own Site box rather than fall under "Other wiki's". That would allow us to link an item to its corresponding Gallery, Category, Creator or whatever. Right now we can only like to Commons category via the Other Wiki's and although we can link Galleries, Creator and the like as data items, they are not "linked" as site links.
>
> This would be very useful - I think this would be a good way forward that would avoid the whole 'page vs. category' debate. The Phabricator ticket is at:
> https://phabricator.wikimedia.org/T102417
>
> Thanks,
> Mike
> _______________________________________________
> Commons-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/commons-l

_______________________________________________
Commons-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikidata] Trends in links from Wikidata items to Commons

Romaine Wiki-2
In reply to this post by James Heald
> 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 <[hidden email]>:
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: [hidden email]
To: [hidden email]; [hidden email]
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 <[hidden email]>:
2015-08-28 12:09 GMT+02:00 Romaine Wiki <[hidden email]>:

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

[hidden email]

https://lists.wikimedia.org/mailman/listinfo/wikidata




_______________________________________________
Commons-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l                                 



_______________________________________________
Commons-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l



_______________________________________________
Commons-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l


_______________________________________________
Commons-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikidata] Trends in links from Wikidata items to Commons

Romaine Wiki-2
In reply to this post by Gerard Meijssen-3
Sorry to say but I think that Commons categories remain when Wikidata type technology is applied on Commons, as Wikidata type technology is not suitable for the basic functionalities the Commons categories are used for.

Queries are not a replacement for Commons categories.

Romaine



2015-08-30 20:30 GMT+02:00 Gerard Meijssen <[hidden email]>:
Hoi.
The problem with Commons is that its categories will be largely redundant once Wikidata type technology will replace them, It will be just a question of having a query for the result that you want.. If you want to have fences in mauve, by all means, query for it but there may be the surprise that there are none.

Creating items for categories for Commons is imho an exercise in futility.. What is the point after all ? Having those categories may mean that we have a clue what queries are of interest..So when people add those categories, it is current best practice.
Thanks,
     GerardM

On 30 August 2015 at 16:51, Gnangarra <[hidden email]> wrote:
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) <[hidden email]> 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
[hidden email]
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l



_______________________________________________
Commons-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l



_______________________________________________
Commons-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikidata] Trends in links from Wikidata items to Commons

Gerard Meijssen-3
In reply to this post by Daniel Schwen-2
Hoi,
Killing categories on Commons is a bit premature. Until the time we start working in earnest on Commons, it is probably not the categories we will do first. Easiest and more obvious are data that is of relevance and is kept in templates like the "Creator" or the "Institution" template. As it is, a majority of them are already linked to Wikidata. Making a complete change for having this data in Wikidata means that such information is available in all languages. Another aspect is in data like licenses and similar info. That could be done easy as well because it is already largely structured.

Categories on Commons are "peculiar". It will be interesting what the discussions will be once it will be discussed in earnest.
Thanks,
     GerardM

On 13 September 2015 at 20:39, Daniel Schwen <[hidden email]> wrote:
Hi all,
before we write off the category system (as
living-in-the-future-Gerard seems to do ;-) we should probably rather
think about killing galleries. All of them. Completely. Galleries
require a considerable maintenance overhead, and I would argue that
that work is better spent on categorizing our content. We could
replace galleries by allowing select images to retain high level
categories (for example through a template so the don't accidentally
get diffused down the tree). The captions in galleries are just an
i18n nightmare and a data duplication of the description texts.
This does not entirely solve the problem of still having the Creator
namespace, but if were up to me, we'd _not_ interwikilink there, but
rather to the "Works by .." category, because that is what I think
people expect to find on commons: Images
Cheers,
Daniel

On Sun, Aug 30, 2015 at 2:36 PM, Michael Peel <[hidden email]> wrote:
>
>> On 28 Aug 2015, at 18:40, Reguyla <[hidden email]> wrote:
>>
>> This is one reason I create the pahbricator request for Commons to have its own Site box rather than fall under "Other wiki's". That would allow us to link an item to its corresponding Gallery, Category, Creator or whatever. Right now we can only like to Commons category via the Other Wiki's and although we can link Galleries, Creator and the like as data items, they are not "linked" as site links.
>
> This would be very useful - I think this would be a good way forward that would avoid the whole 'page vs. category' debate. The Phabricator ticket is at:
> https://phabricator.wikimedia.org/T102417
>
> Thanks,
> Mike
> _______________________________________________
> Commons-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/commons-l

_______________________________________________
Commons-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l


_______________________________________________
Commons-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikidata] Trends in links from Wikidata items to Commons

Romaine Wiki-2
In reply to this post by Gerard Meijssen-3
Categories are not error prone, it are humans. And this means that as result this applies also to queries. Both depend on the quality of the edits users make, and both are as problematic.

I am 100% sure that wikibase technology can be helpful and improve the search for and use of images, but is not a replacement for stable categories and their pages. That it will be available in many languages is nice, but still a stable page system to categorise images is needed. I consider it much more likely that categories are converted in such way that the images in a category are added to an ID, instead of a language depended category name, and yes, that sounds much like a wikibase system, but is not exactly the same.

One of the most important usage of categories on Commons is navigation. Looking to the way how Wikidata is, navigation through groups of pages is hopeless. On Commons this type of navigation is essential and Commons can't be without.

But still, this subject is irrelevant for this discussion, as the problem situation still remains: from Commons to Wikidata there are two groups of pages to link to: articles and categories.

Romaine



2015-08-30 20:52 GMT+02:00 Gerard Meijssen <[hidden email]>:
Hoi,
A category includes images that have shared characteristics.  The problem with categories is that they are error prone, mistakes are made or they are just not added or understood. A category like "Frisian stallions" has obviously stallions of the Frisian breed in them.  When an image is known to have a "Friese stamboekhengst" in Dutch, you do not need to add a text for "Frisian stallion". Because one is the translation of the other. You can search for all the paintings by 文森·梵谷 and tind the same paintings I would when I seek them for Vincent van Gogh.

There is nothing wrong with having categories at this time. It is just that once we add statements, the same information will be available in every other language. We cannot do it now. The whole current issue with Wikidata is not that relevant as it will change when development time is put into place and have Wikidata type annotations and queries in a way that is not only but also English.
Thanks,
      GerardM

On 30 August 2015 at 20:37, Steinsplitter Wiki <[hidden email]> wrote:
>>The problem with Commons is that its categories will be largely redundant once Wikidata type technology will replace them

Can you elaborate please? What is replacing commons category system?

...


From: [hidden email]
Date: Sun, 30 Aug 2015 20:30:36 +0200
To: [hidden email]
Subject: Re: [Commons-l] [Wikidata] Trends in links from Wikidata items to Commons

Hoi.
The problem with Commons is that its categories will be largely redundant once Wikidata type technology will replace them, It will be just a question of having a query for the result that you want.. If you want to have fences in mauve, by all means, query for it but there may be the surprise that there are none.

Creating items for categories for Commons is imho an exercise in futility.. What is the point after all ? Having those categories may mean that we have a clue what queries are of interest..So when people add those categories, it is current best practice.
Thanks,
     GerardM

On 30 August 2015 at 16:51, Gnangarra <[hidden email]> wrote:
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) <[hidden email]> 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
[hidden email]
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l



_______________________________________________ Commons-l mailing list [hidden email] https://lists.wikimedia.org/mailman/listinfo/commons-l

_______________________________________________
Commons-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l



_______________________________________________
Commons-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l



_______________________________________________
Commons-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l
Reply | Threaded
Open this post in threaded view
|

Re: [Wikidata] Trends in links from Wikidata items to Commons

Gerard Meijssen-3
Hoi,
<grin> Commons categories are hopeless when you do not speak English. </grin> I do not care for them at all. When functionality opens data for people who do not speak English, then by all means take care of the categories but do understand that it will be no longer for "all of us". 

When you navigate Wikidata data in "Reasonator", it is really usable and useful in any language. I totally agree about navigating within Wikidata; I do not navigate data in Wikidata. I use Wikidata for editing only.
Thanks,
      GerardM

On 13 September 2015 at 21:39, Romaine Wiki <[hidden email]> wrote:
Categories are not error prone, it are humans. And this means that as result this applies also to queries. Both depend on the quality of the edits users make, and both are as problematic.

I am 100% sure that wikibase technology can be helpful and improve the search for and use of images, but is not a replacement for stable categories and their pages. That it will be available in many languages is nice, but still a stable page system to categorise images is needed. I consider it much more likely that categories are converted in such way that the images in a category are added to an ID, instead of a language depended category name, and yes, that sounds much like a wikibase system, but is not exactly the same.

One of the most important usage of categories on Commons is navigation. Looking to the way how Wikidata is, navigation through groups of pages is hopeless. On Commons this type of navigation is essential and Commons can't be without.

But still, this subject is irrelevant for this discussion, as the problem situation still remains: from Commons to Wikidata there are two groups of pages to link to: articles and categories.

Romaine



2015-08-30 20:52 GMT+02:00 Gerard Meijssen <[hidden email]>:
Hoi,
A category includes images that have shared characteristics.  The problem with categories is that they are error prone, mistakes are made or they are just not added or understood. A category like "Frisian stallions" has obviously stallions of the Frisian breed in them.  When an image is known to have a "Friese stamboekhengst" in Dutch, you do not need to add a text for "Frisian stallion". Because one is the translation of the other. You can search for all the paintings by 文森·梵谷 and tind the same paintings I would when I seek them for Vincent van Gogh.

There is nothing wrong with having categories at this time. It is just that once we add statements, the same information will be available in every other language. We cannot do it now. The whole current issue with Wikidata is not that relevant as it will change when development time is put into place and have Wikidata type annotations and queries in a way that is not only but also English.
Thanks,
      GerardM

On 30 August 2015 at 20:37, Steinsplitter Wiki <[hidden email]> wrote:
>>The problem with Commons is that its categories will be largely redundant once Wikidata type technology will replace them

Can you elaborate please? What is replacing commons category system?

...


From: [hidden email]
Date: Sun, 30 Aug 2015 20:30:36 +0200
To: [hidden email]
Subject: Re: [Commons-l] [Wikidata] Trends in links from Wikidata items to Commons

Hoi.
The problem with Commons is that its categories will be largely redundant once Wikidata type technology will replace them, It will be just a question of having a query for the result that you want.. If you want to have fences in mauve, by all means, query for it but there may be the surprise that there are none.

Creating items for categories for Commons is imho an exercise in futility.. What is the point after all ? Having those categories may mean that we have a clue what queries are of interest..So when people add those categories, it is current best practice.
Thanks,
     GerardM

On 30 August 2015 at 16:51, Gnangarra <[hidden email]> wrote:
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) <[hidden email]> 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
[hidden email]
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l



_______________________________________________ Commons-l mailing list [hidden email] https://lists.wikimedia.org/mailman/listinfo/commons-l

_______________________________________________
Commons-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l



_______________________________________________
Commons-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l



_______________________________________________
Commons-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l



_______________________________________________
Commons-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/commons-l
12