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

[Romaine Wiki]

@ 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.w...@gmail.com
>> To: wikidata@lists.wikimedia.org; common...@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 <martinellil...@gmail.com>:
>> 2015-08-28 12:09 GMT+02:00 Romaine Wiki <romaine.w...@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

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

[Joe Filceolaire]

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-w...@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: gnanga...@gmail.com
> To: common...@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) <nemow...@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
> common...@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
> common...@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
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] [Commons-l] 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)  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
> common...@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
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

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

[Yann Forget]

Hi, I can only say that I agree 100% with Steinsplitter.

Yann

2015-08-29 15:39 GMT+02:00 Steinsplitter Wiki steinsplitter-w...@live.com:
 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.

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

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

[James Heald]

.


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.w...@gmail.com
To: wikidata@lists.wikimedia.org; common...@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 martinellil...@gmail.com:
2015-08-28 12:09 GMT+02:00 Romaine Wiki romaine.w...@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
common...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/commons-l  




___
Commons-l mailing list
common...@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

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

[Reguyla]

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 romaine.w...@gmail.com
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 romaine.w...@gmail.com:

 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 j.he...@ucl.ac.uk:

 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