Re: [Wikimedia-l] Rethinking Commons paradigms with Wikidata // was The tragedy of Commons
An example of a crowd-sourced tagger: http://tagger.thepcf.org.uk/tutorial/ Something similar could be thought for Commons if the property depicts were available. On Fri, Jun 20, 2014 at 7:48 PM, David Cuenca dacu...@gmail.com wrote: Which btw is open source http://levan.cs.washington.edu/ngrams/README.txt On Fri, Jun 20, 2014 at 7:42 PM, David Cuenca dacu...@gmail.com wrote: And all this about structured data gets even more interesting when you combine it with machine learning, like in LEVAN https://www.youtube.com/watch?v=kg4As_JLR84 http://levan.cs.washington.edu/?state=fetchNGramsconcept=apple -- Etiamsi omnes, ego non -- Etiamsi omnes, ego non ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Rethinking Commons paradigms with Wikidata // was The tragedy of Commons
Which btw is open source http://levan.cs.washington.edu/ngrams/README.txt On Fri, Jun 20, 2014 at 7:42 PM, David Cuenca dacu...@gmail.com wrote: And all this about structured data gets even more interesting when you combine it with machine learning, like in LEVAN https://www.youtube.com/watch?v=kg4As_JLR84 http://levan.cs.washington.edu/?state=fetchNGramsconcept=apple -- Etiamsi omnes, ego non ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
[Wikimedia-l] Rethinking Commons paradigms with Wikidata // was The tragedy of Commons
On Wed, Jun 18, 2014 at 6:58 PM, Fæ fae...@gmail.com wrote: In the meantime, it might be an idea for folks to avoid claiming that any issue that pops up on Commons can be solved in Wikidata, unless they can produce a working case study rather than discussion about proposals. One of the Commons parts that could benefit most from Wikidata are the content pages, aka Galleries. Right now they are volunteer-maintained and they look like this: https://commons.wikimedia.org/wiki/Sagrada_Fam%C3%ADlia But it doesn't need to be so, these pages could be automated, so the page is composed by querying images and sorting them automatically. Of course volunteer intervention would be also needed to define the queries, but it would be more sustainable than now (i.e. the page would be automatically updated with new images if they meet the query criteria). To achieve this it would be necessary to re-think Galleries, and consider other paradigms, like that used by IMSLP. Check for instance: http://imslp.org/wiki/Tristan_und_Isolde,_WWV_90_(Wagner,_Richard) That is a page for the work, and the different expressions/files are structured in one page. This structure however is volunteer-maintained, but it is to consider each file as a metadata container, and the section as the result of a query. This approach is not followed in Commons, that is more category-oriented. Going back to the original Sagrada Familia gallery example: - the header data can be extracted from Wikidata with a Lua template. That can be done now, no need to wait, just needs a Lua template and connect with Wikidata via sitelink. - each section would be a query for instance depicts:sagrada familia AND depicts:exterior. - each file would be needed to be tagged accordingly with structured data, and it would show up in the gallery page. Galleries, thus, would become the hub where all media related to a subject could be accessed. That, of course, would be too many images, considering that just the Towers of Sagrada familia category has 159 images: https://commons.wikimedia.org/wiki/Category:Towers_of_the_Sagrada_Fam%C3%ADlia That means that it would be needed to limit query results and define criteria to decide which images to show, and let the user expand the full query when wished. Or another page (gallery) could be created for the Towers of Sagrada familia, which in turn could contain more queries for further details about the the towers depicts:sagrada familia AND depicts:exterior AND depicts:right tower AND NOT depicts:left tower. Categories would be rendered superfluous, with the focus shifted towards maintaining queries and the proper description of image files with structured data. Anyhow, these are just some ideas to show that there are different ways of working with media that might be more effective in the long run. Cheers, Micru ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] Rethinking Commons paradigms with Wikidata // was The tragedy of Commons
Though I like the IMSLP approach, I still like the totally free format of Commons galleries, and many categories have more than one gallery, so a standard approach may not work well. I do think WikiData can help with image navigation somehow, but I am just not sure how. As I understood Lua, this won't help. quote Categories would be rendered superfluous, with the focus shifted towards maintaining queries and the proper description of image files with structured data. /unquote Ahh - the dream of every Wiki(p/m)edian who has hit the wall on category limitations! I don't believe they will ever become superfluous. Rather, I think we should be increasing the use of categories (using them almost like tags) and even allowing empty categories using placeholders taken from existing Wikipedia articles that are missing pictures. Also, I don't think many of our Sagrada familia photo contributors have an idea what a query is, nor do they care about structured data. Using your example, We could split the Towers of Sagrada familia into each tower, then into each sculpture on each tower, etc. Volunteers decide the structure of the categories that may or may not match up with WikiData items, but only filled categories are visible to the casual browser. The next time someone uploads something into the default Sagrada Familia category, there could be push messages to the uploader displaying something from the empty category placeholders, along the lines of Z-language Wikipedia is missing a picture of X tower - does this file show that? The WLM project has a rough version of this with the easy upload link for the unique identifiers: https://en.wikipedia.org/wiki/Wiki_Loves_Monuments#Unique_identifiers This puts the infrastructure on Wikipedia along with the prompt to upload. It would be nice if the prompt to upload could be on Commons directly. On Thu, Jun 19, 2014 at 11:51 AM, David Cuenca dacu...@gmail.com wrote: On Wed, Jun 18, 2014 at 6:58 PM, Fæ fae...@gmail.com wrote: In the meantime, it might be an idea for folks to avoid claiming that any issue that pops up on Commons can be solved in Wikidata, unless they can produce a working case study rather than discussion about proposals. One of the Commons parts that could benefit most from Wikidata are the content pages, aka Galleries. Right now they are volunteer-maintained and they look like this: https://commons.wikimedia.org/wiki/Sagrada_Fam%C3%ADlia But it doesn't need to be so, these pages could be automated, so the page is composed by querying images and sorting them automatically. Of course volunteer intervention would be also needed to define the queries, but it would be more sustainable than now (i.e. the page would be automatically updated with new images if they meet the query criteria). To achieve this it would be necessary to re-think Galleries, and consider other paradigms, like that used by IMSLP. Check for instance: http://imslp.org/wiki/Tristan_und_Isolde,_WWV_90_(Wagner,_Richard) That is a page for the work, and the different expressions/files are structured in one page. This structure however is volunteer-maintained, but it is to consider each file as a metadata container, and the section as the result of a query. This approach is not followed in Commons, that is more category-oriented. Going back to the original Sagrada Familia gallery example: - the header data can be extracted from Wikidata with a Lua template. That can be done now, no need to wait, just needs a Lua template and connect with Wikidata via sitelink. - each section would be a query for instance depicts:sagrada familia AND depicts:exterior. - each file would be needed to be tagged accordingly with structured data, and it would show up in the gallery page. Galleries, thus, would become the hub where all media related to a subject could be accessed. That, of course, would be too many images, considering that just the Towers of Sagrada familia category has 159 images: https://commons.wikimedia.org/wiki/Category:Towers_of_the_Sagrada_Fam%C3%ADlia That means that it would be needed to limit query results and define criteria to decide which images to show, and let the user expand the full query when wished. Or another page (gallery) could be created for the Towers of Sagrada familia, which in turn could contain more queries for further details about the the towers depicts:sagrada familia AND depicts:exterior AND depicts:right tower AND NOT depicts:left tower. Categories would be rendered superfluous, with the focus shifted towards maintaining queries and the proper description of image files with structured data. Anyhow, these are just some ideas to show that there are different ways of working with media that might be more effective in the long run. Cheers, Micru ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Re: [Wikimedia-l] Rethinking Commons paradigms with Wikidata // was The tragedy of Commons
On Thu, Jun 19, 2014 at 1:24 PM, Jane Darnell jane...@gmail.com wrote: Though I like the IMSLP approach, I still like the totally free format of Commons galleries, and many categories have more than one gallery, so a standard approach may not work well. I do think WikiData can help with image navigation somehow, but I am just not sure how. As I understood Lua, this won't help. It doesn't need to be a fixed structure, it can be a mix with some static media galleries, and some dynamic galleries defined with Ask: https://semantic-mediawiki.org/wiki/Help:Inline_queries Ahh - the dream of every Wiki(p/m)edian who has hit the wall on category limitations! I don't believe they will ever become superfluous. Rather, I think we should be increasing the use of categories (using them almost like tags) and even allowing empty categories using placeholders taken from existing Wikipedia articles that are missing pictures. They could be complementary. For instance, there could be bots that would tag images in the category sagrada familia as depicts:sagrada familia. And the other way round too. Also, I don't think many of our Sagrada familia photo contributors have an idea what a query is, nor do they care about structured data. And neither they should! Better to ask: what is in the picture? and let them pick any item from wikidata to tag it with. Using your example, We could split the Towers of Sagrada familia into each tower, then into each sculpture on each tower, etc. Volunteers decide the structure of the categories that may or may not match up with WikiData items, but only filled categories are visible to the casual browser. The next time someone uploads something into the default Sagrada Familia category, there could be push messages to the uploader displaying something from the empty category placeholders, along the lines of Z-language Wikipedia is missing a picture of X tower - does this file show that? Excellent idea! Actually any part of Sagrada Familia that can have a gallery page, could fulfill the criteria for having a Wikidata item. There we can store data about the item and its relation with the whole (sagrada familia right towerpart ofSagrada Familia) or about the height, builders, status, etc. Then it becomes trivial to display the whole tree and signal which parts are missing. As an example of tree check: http://tools.wmflabs.org/wikidata-todo/tree.html?q=Q1785783rp=361lang=enmethod=listdepth=4 If this tree was connected with Commons, then I could know which compositions miss audio and try to find a recording. Same for any building that can be partitioned. Just build the concept tree in Wikidata, tag the images appropriately and then you have a very nice overview about which parts miss pictures. The WLM project has a rough version of this with the easy upload link for the unique identifiers: https://en.wikipedia.org/wiki/Wiki_Loves_Monuments#Unique_identifiers This puts the infrastructure on Wikipedia along with the prompt to upload. It would be nice if the prompt to upload could be on Commons directly. Perfect, later on it could be used a standard wikidata identifier to tag images with the same result. Micru ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
