Wikidata talk:WikiProject Commons

Infoboxes

A first task could be to start working on c:Commons:Infoboxes, listing the parameters of each infobox that belong to Commons and the ones that should be stored here on Wikidata. For c:Template:Book and c:Template:Artwork the job is mostly done, except for the fields "source", "permission", and some other properties related to the file. It is also worth noting that the structure for Books can be quite complex when considering all 4 abstraction levels (in accordance with FRBR, the model being implemented by UK and US libraries as RDA), but should that complexity be hidden to the user or is it worth indicating to the user somehow? (possible options are different color shades or a different template layout)

c:Template:Photograph, c:Template:Art photo and c:Template:Musical work would benefit from a supporting WikiProject to attract wider communities from the wikipedias. The challenge is to advertise it in several languages.

Creator and Institution templates seem to be easily adaptable, I don't know if there are custom cases that require attention. --Micru (talk) 07:50, 17 August 2014 (UTC)

If I'm not mistaken, User:Jarekt linked lot of Wikidata items to templates based on commons:Template:Creator. It'll be good start, especially from localization point of view. --EugeneZelenko (talk) 14:04, 17 August 2014 (UTC)

We should probably set up specific sub-pages here to track the most important classes of templates. Jheald (talk) 14:28, 17 August 2014 (UTC)

@Micru: You're right that the page you link above would be a good start. We could make a local copy here, and then start colouring it in, for what's possible and what's done, as we produce prototype versions that can draw from Wikidata. Jheald (talk) 14:52, 18 August 2014 (UTC)

Jarekt's bot did a lot. There's a maintenance cat at c:Category:Creator template maintenance which tracks various issues, including c:Category:Creator templates without Wikidata link, which currently shows 8,338 members, out of 18,196 creator templates in total. Jheald (talk) 14:35, 17 August 2014 (UTC)

Checking conformance with the category-category and article-article interwiki constraint

We're going to need a tool that checks Commons categories are only linked to category-like items, and Commons articles to article-like ones, per c:Commons:Wikidata/Commons-Wikidata sitelinks.

Either Autolist or Autolist 2 can be fed WDQs to find that

 CLAIM[31:4167836] AND LINK[commonswiki]

identifies 250907 items which are categories that have sitelinks to Commons, and

 LINK[commonswiki] AND NOCLAIM[31:4167836]

indentifies 172065 items which are not categories that have sitelinks to Commons.

But it seems hard to confirm how many of these links do or don't point to actual categories on Commons, ie to find out how many of those links to Commons actually start :Commons:Category:, and how many of them do not ?

We should also be routinely constraint-checking the integrity of 'connector' properties like Commons category (P373), Commons gallery (P935), topic's main category (P910) and category's main topic (P301), cf User:Multichill/Cross namespace. Jheald (talk) 13:25, 17 August 2014 (UTC)

User:Multichill has also set up Wikidata:Commons category tracking, which (I think) relies on scripts to have been run. But it would be nice to know if there was a query to do this directly. Jheald (talk) 14:22, 17 August 2014 (UTC)

This is pretty easy to pull from the database, see for example User:Multichill/Cross namespace. This page excludes Commons at the moment, but it isn't that hard to make it for Commons too.

On a sidenote, did you notice Wikidata:Database_reports/Constraint_violations/P373#.22Existing_category.22_violations? Multichill (talk) 14:29, 17 August 2014 (UTC)

Commons is a particularly interesting category to look at for the cross-namespace, because historically so many commonscats have been linked to wiki articles. Jheald (talk) 17:02, 17 August 2014 (UTC)

Some more numbers for various things now at Wikidata talk:WikiProject Structured Data for Commons/Statistics. Jheald (talk) 18:41, 17 August 2014 (UTC)

Item discovery

One of the things that is difficult at the moment, and often has to be done laboriously by hand after a batch upload, is Category discovery on Commons, and whether there are any wikipedia articles to link.

It could be useful to write a guide to what discovery tools are available on Wikidata that can help automate the process, and how they compare to current tools on Commons. Jheald (talk) 13:32, 17 August 2014 (UTC)

Things that could work now (or at least, as soon as Commons Phase 2 gets turned on)

Lydia has said recently that she sees little point in turning on Phase 2 for Commons, because without Arbitrary Access, there will be very little benefit. (And she doesn't want people to create Q-numbers for files).

But this is not true.

• Categories could benefit with automated multilingual links to corresponding articles in Wikipedias.
  • This would take a lot of pressure off the Interwiki links (probably) not going to articles
• Similarly, a standard header for galleries, pointing to articles; and also (multilingualised) the corresponding Commons category, if there is one -- drawing automatically from Wikidata.
• Galleries could gain a lot from information drawn from Wikidata (even if the more important case, categories, had to wait for arbitrary access).
  • eg the top of c:London -- currently coded by hand
  • Infoboxes that appear on Galleries (as distinct from the infoboxes used on filepages, discussed by Micru in thread #1 at the top)

We need to start getting to grips with just what templates are in use, and what could be built; but with a bit of work (and particularly if the sitelinks controversy gets sorted out), we should be able to put together a solid case for Lydia to turn on Stage 2. Jheald (talk) 16:20, 17 August 2014 (UTC)

Unfortunately, the c:Commons:WikiProject Templates seems rather moribund. Jheald (talk) 16:58, 17 August 2014 (UTC)

For clarification: I can be convinced to turn on phase 2 if we can agree to not store file metadata here. --Lydia Pintscher (WMDE) (talk) 20:08, 17 August 2014 (UTC)

@Lydia Pintscher (WMDE): when you say "not to store file metadata here" can we clarify exactly what you mean?

What I presume you to mean is "don't create Q-numbers for individual files" and that seems fine. The key thing here is the Wikidata:Notability guidelines, which state that at the moment that an item must either contain one valid sitelink (which will not be true for a filepage, because they are explicitly excluded); or it must refer to a "clearly identifiable conceptual or material entity" (which a Commons image page is not); or it must "fulfil some structural need", but it's hard to see how that would be the case.

What will eventually will be interesting will be to think about the statements you might want to make about files; but for the moment it should be quite enough to think about statements one wants to make about real things that already have Q-numbers -- paintings, painters, locations, themes, artistic movements, etc (ontologies for which have already been greatly developed by eg the Books and the Visual Arts projects). It's premature, I think, to think much beyond that at this stage -- until the structure of Commons WikiBase is much clearer, what we're going to be working with at this stage is templates on a file page presenting properties defined on existing Q-numbers; that seems quite enough for the time being.

The point about Commons categories is also quite clear: they are not considered notable unless they correspond to something else that has a Q-number. A category of somebody's Flickr photographs is not notable just because it has a Commons category.

One thing I would like to know more about is how accurately the category-category and gallery-article linking requirements are being maintained, because I think that is going to be quite important for predictability of templates. User:Multichill says he has a tool which should be able give the numbers on that quite easily. Also I think it would be good to get some simple templates developed that can sit at the top of categories and galleries and do useful things in lots of languages (for categories that pass notability). But really I think the sooner we start phase 2 the better, because then people will start to be able to see what Wikidata can do for them, and that will boost interest. Jheald (talk) 21:28, 17 August 2014 (UTC)

Yeah I am mostly concerned about people creating items for individual files. It's excluded per the notability guideline indeed. As long as we're clear on this and there is no major opposition I am good with turning it on. --Lydia Pintscher (WMDE) (talk) 21:31, 17 August 2014 (UTC)

c:COM:AN

For your information, this page is currently being discussed at c:COM:AN#d:Wikidata:WikiProject Structured Data for Commons. --Stefan2 (talk) 21:37, 17 August 2014 (UTC)

Centralizing image requests

Does anybody think that we could also centralize image requests on Wikidata? And possibly connect the requests to the Commons app ([1])? Currently all requests are spread over a lot of pages (Wikipedia:Requested Pictures (Q6750881)) and are only semi-machine-readable. It seems that on Wikidata we could easily connect request with their respective items (and their coordinates). -Tobias1984 (talk) 22:04, 17 August 2014 (UTC)

Tabs

I've created a first set of tabs to help us organise ourselves. Feel free to change as desired. Jheald (talk) 03:35, 19 August 2014 (UTC)

Categories and tags

Personally, I think the move to structured data for Commons is the perfect opportunity for us to move away from categories and towards a tag-based system of organization. Rather than reproducing the category data in Wikidata, I think we should start fresh and only have tag data for media in Wikidata. So, for example, instead of an image of a blonde male teenager seated on motorcycle facing right in Austria being assigned to the following categories...

• Blonde male teenagers
• Blonde males on motorcycles
• Blonde males facing right
• Blonde males in Austria
• Blonde teenagers on motorcycles
• Blonde teenagers facing right
• Blonde teenagers in Austria
• Blondes on motorcycles facing right
• Blondes on motorcycles in Austria
• Blondes facing right in Austria
• Male teenagers on motorcycles
• Male teenagers facing right
• Male teenagers in Austria
• Males on motorcycles facing right
• Males on motorcycles in Austria
• Males facing right in Austria
• Teenagers on motorcycles facing right
• Teenagers on motorcycles in Austria
• Teenagers facing right in Austria
• ad absurdum

...we would have the following tags assigned to the image instead: "male, human, blonde, teenager, seated, motorcycle, facing right, Austria". Then people could actually find the images they are looking for on Commons! Kaldari (talk) 18:36, 19 August 2014 (UTC)

In theory yes. And I think this should be the goal we are gradually working towards. However can we please not call them tags but topics instead? There are important distinctions. They're not free-text. They are multi-lingual. They are referring to specific concepts (allowing us to distinguish orange the color and the fruit for example). And they have associated descriptions, articles and more to help people understand the meaning behind it. --Lydia Pintscher (WMDE) (talk) 18:41, 19 August 2014 (UTC)

@Kaldari: - We already had a similar discussion a while ago about the curated default image property of Wikidata: Wikidata:Requests for comment/Image properties: many properties or many qualifiers. I agree that the category system needs to be generated from Wikidata-statements and not the way it is done now. Replicating this in all languages can be compared to the life of Sisyphus (Q102561). The only thing I would add to your example is that if the picture has geocoordinates, then we need a bot to add the specific place (e.g. Vienna: queries can then ask for Austria). In general we should choose the lowest point to enter into the ontology. If we know the motocycle-model then we should add that in the statement. -Tobias1984 (talk) 13:05, 20 August 2014 (UTC)

I've always disliked this "diffusion" of large categories as it is called, which comes from an inability to browse or search intersections of simple, large categories, and I welcome the concept of topics (especially their internationalization). A problem with any kind of metadata in Commons is the confusion of the attributes of the media itself and what it depicts. Topics should relate to the content of the media, so that categories such as commons:Category:1520s oil on canvas paintings are redundant to the ability to search by the properties of the depicted media (the date of creation and medium of paintings in this case, but also current location, place of origin, etc. etc.), whereas information about what is depicted (pumpkins, the martyrdom of Saint Bartholemew, hyraxes, heart bypasses, etc.) are more suitable as topics. One thing I foresee is that different languages have different ontologies and there is never a one-to-one mapping of denotations (no distinction between a dove and a pigeon in non-English, no distinction between green and blue in Japanese), which is a problem for i18n -Moogsi (talk) 15:24, 24 August 2014 (UTC)

Kaldari, don't say tags, say topics. Read Commons:User:Multichill/Next generation categories. I wrote that back in 2011, with Wikibase staments we're able to do that. Setting up this whole new system on Commons is interesting, but the hard part is going to be the conversion from one system to another. My gut feeling says we should first focus on the templated part of our image pages (license templates, source templates, etc) to get the hang of it. After a while we could take on the topic challenge. As a community (the Commons community that is), we need to figure out the possibilities and steps and reach consensus on that. Multichill (talk) 16:10, 24 August 2014 (UTC)

@Multichill: That all sounds sensible and similar to what I've argued for at the Commons discussion. Kaldari (talk) 22:09, 25 August 2014 (UTC)

@Multichill, Kaldari: We already have two properties for works:

• depicts (P180): what is shown in the picture
• main subject (P921): what is the picture about

For instance Charles IV in his Hunting Clothes (Q5079271) depicts a person, but the work is about hunting. I guess you would need other properties about the picture itself (distance, location, perspective, etc).--Micru (talk) 07:39, 26 August 2014 (UTC)

(Sorry, the post below is long, and contains rather a lot of different points. But I think as a whole this is one of the most important questions, and there are a lot of angles to think about. So I hope you can forgive me the length, and the variousness of themes. Jheald (talk) 10:56, 28 August 2014 (UTC) )

To expand on some of what I've said over in the Commons discussion, I think we should expect categories to be around for a long time to come -- nobody should be writing their obituary; so thinking or saying that they might be going to disappear as a result of the structured data plan I think would just be to associate unnecessary fear uncertainty and dread with the project.

Yes, what we now think of as categories will become very integrated with structured data plans; it is likely that it will become possible to add exciting new fuctionality to the current views; and some hand-curation of categories may become redundant and fall by the wayside. But as a whole, I think Category-like items and views are not going to go away (so need to be planned for).

The key thing is I think there will continue to be a need to attach information to (some) sets of images as sets. For example, consider c:Category:Images released by British Library Images Online, relating to a particular set of images released by a particular institution on a particular date; or c:Category:Metropolitan Improvements (1828) Thomas Hosmer Shepherd, a particular set of scans from a particular edition of a particular book. These are not entities that would currently pass Wikidata:Notability. The book, and even the edition, might. But a particular set of scans would not. Similarly, the first category is really just a photoset from Flickr, again something that wouldn't currently get a Wikidata Q-number. Now on the mailing list recently Lydia effectively said, no problem, for simplicity just give any such categories a Q-number. But I think that would be a mistake. IMO there is value in sticking to WD:N -- it means people can download a dump of Wikidata for their own purposes, and get real-world relevant items, rather than the dump being bloated with wiki junk. So in my opinion, Commons categories should generally not get Q-numbers on Wikidata (unless they pass WD:N), but should instead get items on Commons Wikibase (an item with a C-number, perhaps).

Anyway, regardless of whether one makes an item for it on Wikidata or on Commons, the underlying point I'm making is that a category is not (necessarily) just a query -- in each of the cases above, the category view contains additional information about that particular set of images. And indeed, some of this could very usefully be templated/automated to read some of the appropriate information from relevant Q-numbers on Wikidata or C-numbers on Commons. But (IMO) there remains also a value in being able to add free-form wiki text.

Some other useful features of the current category system are the ease with which one can create new categories ad-hoc; the ease with which add one can add images to categories, using toys like eg Cat-a-lot to select multiple files; and the abilitiy to add categorisation as one of the effects of a template. Looking at these features, I would expect analogues of Cat-a-lot to appear very quickly, updating category-like metadata via the structured data API rather than wikitext; I am not sure how easy it will be to create new curated categories; but what I wonder most about is categorisation-through-templates. This is a very useful thing, to be able to display a message and set a categorisation in one go, simply by making a very simple edit to the wikitext. This of course how tracking of maintenance templates works; but it is also widely used for file information, for example by GLAM source/credit templates like c:Template:British library image, c:Template:Mechanical Curator image or c:Template:BL1million bookcat, all of which display a message, act as specialised containers for some (somewhat) structured data, and set some appropriate categorisations based on that data -- all by adding some very short wikitext.

One thing that should be very valuable with the topic-based search should be the ability to prompt the user to refine their search in a context-specific way. Identifying the most likely/interesting refinements to offer the searcher at each stage will be an interesting exercise, presumably including thoughts from information theory (most informative refinement topics/topic-types to offer next) and user tacking/analytics (refinement topics/topic-types most often sought next). To some extent I agree that this is likely to give a much more flexible and maintainable way to return hits for queries like the original poster's "blonde male teenager seated on motorcycle facing right in Austria". But not all Commons categories are so arbitrarily combinatorial. Often Commons cats do present natural sets, sometimes naturally closed sets, and sometimes natural identified and curated hierarchies. This should not be thrown away, no matter how shiny are the new AI-driven automated topic-refinement hierarchies we might create to supplement them.

One way forward (IMO), that could provide an evolutionary rather than revolutionary path, keeping the best of both worlds, might be to allow categories to be augmented with specific queries, by allowing rules to be specified for particular categories, so that files whose structured-data topic information matched the rules would automatically be added to the categories, alongside the files already there. Categories, including intersection categories, would therefore effectively auto-update, without human intervention, to include new files if they had appropriate topic information. On the other hand categories could still be specified by hand, and existing legacy categorisation information would survive, allowing the new augmentation approach to slowly come into play if topic information were initially weak. Existing closed categories could be unaffected; and alternatively it could also be made easy to present images that were in a category directly, rather than by virtue of any rule on any metadata, which could then allow such images to be investigated and/or have their topic metadata improved.

It's easy to mock the sometimes extraordinary depths of intersection categories on Commons; such intersection categories are a pain to determine for categorisation, not a very good fit for retrieval, and nor does it well match how the rest of the world does things, which makes metadata import harder and less effective than it should be. But there are virtues in the category system too. There is a wealth of hard-won information encoded in it. And some categories do match natural groupings of images. So an evolutionary approach, it seems to me, would be of value; and I would be interested to know whether people think the category augmentation approach described above would go some way towards making the transition smoother, to an end-point that it seems to me would have additional strengths over a pure query system. Jheald (talk) 10:52, 28 August 2014 (UTC)

@Kaldari, Tobias1984, Moogsi, Multichill, Micru: Any thoughts? Jheald (talk) 08:33, 29 August 2014 (UTC)

@Jheald: I think it is easier to start little by little and let contributors learn how to use the tool and in which way they would like to use it. It's an anti-pattern to plan too much, or to worry too much about problems that are far away in the future.--Micru (talk) 11:24, 29 August 2014 (UTC)

@Jheald: I think it is an excellent plan. Especially the idea about a slow deployment and keeping the best part of both worlds. We should leave the category system intact until a new approach is truly superior. Tobias1984 (talk) 16:17, 29 August 2014 (UTC)

@Jheald: I did write quite a lengthy reply to this, trying to take it point by point, but you make a lot of points here :) - of course no-one will blame you for talking at length because it's a really involved topic, and it's kind of hard to unpick what's important. I think the shortcomings of the category system far outweigh the advantages, and I have a lot of thoughts about what's wrong with it, so I would approach it from that angle when trying to supplement or replace its functionality. I think that in planning to do that, you have to think about what its purpose is and how well it fulfils that purpose. These are very general considerations and it's easy to trip up on very specific things; I know I do when I think about a big topic like this -Moogsi (talk) 20:41, 29 August 2014 (UTC)

@Jheald: That sounded more dismissive than I wanted it to; I agree there are open questions about:

• What to do with metadata about a set of files when it does not meet the notability criteria of any other project (right now it is stored on a category page)
• How topics can make intelligent suggestions when people are browsing for media in the same way that the logical hierarchy of the cat system does. I think the cat system is next to useless for anyone who runs a search for a specific thing. Commons is a media repository, but often it tries to be a database of all things, because that's how one would categorize media of all things. This is the tree at c:Category:Topics. Wikidata is much better suited to this purpose imo.
• How topics should replace categories (I agree that a gradual approach seems like the best bet as far as contributors to and maintainers of Commons are concerned. If my only concern were reusers I'd have no problem being more dismissive of it.

-Moogsi (talk) 21:15, 29 August 2014 (UTC)

Now live: WMF Commons page on the Structured Data project

In case anyone hasn't seen it, the WMF has now put up a page on Commons for the Structured Data project, c:Commons:Structured data, with an invitation to comment on the talk page.

There will also be IRC Q&A sessions, the first one to take place on Wednesday 3 September -- sign up on the Commons page above if you are likely to participate. Jheald (talk) 10:07, 26 August 2014 (UTC)

RfC at Commons

c:Commons:Requests for comment/Structured Commons -- Jheald (talk) 09:09, 1 September 2014 (UTC)

Links to Commons - state of play

Posted at Project chat: Wikidata:Project chat#Links to Commons - state of play, summarising new sets of pages at

• Wikidata:WikiProject Structured Data for Commons/Phase 1 progress/Statistics
• Wikidata:WikiProject Structured Data for Commons/Phase 1 progress/Links

Food for thought! Jheald (talk) 23:22, 5 September 2014 (UTC)

WMF launching drive to revise commons Information and Licensing templates

• m:File_metadata_cleanup_drive

Aim is to make the templates more machine-readable by "adding hidden machine-readable markers to information and copyright templates".

Also to push filepages that don't currently use such templates into using them. Jheald (talk) 07:45, 12 September 2014 (UTC)

For current state of play on Commons, see c:Commons:Machine-readable data, including problems noted there. Jheald (talk) 08:37, 12 September 2014 (UTC)

Files with multiple copyrights

Any idea how files with multiple copyrights will be handled. Here's an example: Josef Suk - Meditation Op 35a.ogg. Kaldari (talk) 06:21, 18 September 2014 (UTC)

A file can contain multiple works. For each work you should be able to set a copyright status/license. Multichill (talk) 08:14, 18 September 2014 (UTC)

@Kaldari: Remember that Wikibase statements can have properties, values and qualifiers.

So if there is a "rights" property, it could take different values, one with a qualifier (which qualifier?) identifying that it applied "for the music", the other with a qualifier "for the performance".

Similarly in User:Multichill's example the qualifier applies to part (P518) could be used.

I would prefer a different qualifier from applies to part (P518), to express the idea that a value relates to a particular (inseverable) aspect of the whole, rather than a particular severable part; but any such new qualifier would probably need to be proposed.

Compare Wikidata_talk:WikiProject_Visual_arts#Engravings:_how_to_record_artists.2C_engravers.2C_publishers_etc_.3F, where the same issue comes up in a different medium.

(I have no idea how the complex situation would be summarised in a 1/4 line licence summary for MediaViewer. There ought to be a central page where the WMF team are developing their thoughts about this; but if it exists, I don't know where it is). Jheald (talk) 09:21, 18 September 2014 (UTC)

Similar comment from Lydia, at c:Commons talk:Structured data (diff). Jheald (talk) 22:59, 19 September 2014 (UTC)

Progress on Creator and Institution templates

See eg

• Template:Creator/wrapper/test
• Template:Institution/statictest

for some progress on trying to make these draw from Wikidata.

Also Wikidata:WikiProject_Structured_Data_for_Commons/Template_workshop#General_approach_for_adapting_existing_Commons_templates for the general approach.

For some specific current challenges, see Template talk:Creator/wrapper/test and Template talk:Creator/statictest; plus Template talk:Creator and Template talk:Institution for (work on) the appropriate Template <-> Wikidata data mappings.

Still very much all work in progress, at quite an early stage, so all help / thoughts / discussion would be very useful. Jheald (talk) 22:57, 19 September 2014 (UTC)

Engravings from books; + whether scan-sets should (sometimes) have individual items

Some discussions at WikiProject Visual Arts, regarding types of items that should / should not be exist on Wikidata, to get ready for the Structured Data project:

• How to treat engravings from books?
• What WikiData items will be needed for the upcoming c:Commons:Structured data to reference?
  • Wikidata_talk:WikiProject_Visual_arts#Wikidata:Notability_and_artwork?

• Could an edition item on Wikidata be enough for information not held on CommonsData about an illustration?
• What if the same engraving appears in different books?
  • Wikidata_talk:WikiProject_Visual_arts#Engravings_reproduced_more_than_once_.28should_CommonsData_property_.22Underlying_work.22_accept_multiple_targets.3F.29

• Where there are a number of pictures from a particular scan-set, should the scan-set have a Wikidata item? (Because there is information we may want to store about the scan-set, eg its source; and we may want to filter by it; and sort members of it according to a qualifier, numerical position in sequence)
  • Wikidata_talk:WikiProject_Visual_arts#Pages_and_scan_numbers._Separate_items_for_scan-sets_.3F

Follow-ups to the Visual Arts talk page. Jheald (talk) 11:28, 21 September 2014 (UTC)

Berlin bootcamp

• Etherpad: Day 1
• Etherpad: Day 2
• Etherpad: Day 3
• Etherpad: Day 4
• Etherpad: Day 5
• Structured data on Phabricator

The team will be updating the Structured Data pages next week, to be followed by another IRC Q&A on Thursday 16th (RSVP)

Jheald (talk) 15:17, 8 October 2014 (UTC)

Exif model and make

You might be interested in the two proposals at Wikidata:Property_proposal/Term#Products_.26_software_products. --- Jura 11:25, 17 July 2015 (UTC)

Wikimania 2016

Only this week left for comments: Wikidata:Wikimania 2016 (Thank you for translating this message). --Tobias1984 (talk) 12:08, 25 November 2015 (UTC)

Some proposed properties needed for compatibility with Commons templates

• Wikidata:Property proposal/Refine date is needed to match the range of dates which use Template:Other date template on Commons.
• date_of_burial is not strictly necessary but it would make life much easier for template writers if date_of_burial was done the same way as dates of birth, death and baptism.
• nationality : Creator templates use it, wikipedia infobox template uses it, and for many people there is no way to save nationality or retrieve it.

--Jarekt (talk) 01:03, 5 September 2017 (UTC)

Structured Data on Commons - community consultation on basic properties for media files

Hello everyone! This month (July 2018), we are hosting a quite crucial community consultation on Wikimedia Commons: we are listing the Wikidata properties that media files on Commons will need (including ones that might not exist yet, and might need to be created for this purpose). The consultation runs at least till the end of July, maybe longer.

Please consider to take a look and give input. Thanks! SandraF (WMF) (talk) 08:56, 4 July 2018 (UTC)

Properties table

I've copied the properties table over from Commons. Where should it be linked to here? Keegan (WMF) (talk) 17:20, 15 October 2018 (UTC)

The question is where to discuss them. I guess probably here. --Juandev (talk) 17:38, 7 September 2019 (UTC)

I added a link to the Commons page in the project main page, as the Commons page is updated and not the Wikidata page. Christian Ferrer (talk) 18:36, 7 September 2019 (UTC)

Request for Comment

Please see this request for comment related to sitelinks to Commons categories and galleries. -- 徵國單  (討論 🀄) (方孔錢 💴) 15:43, 15 January 2019 (UTC)

Request for Comment regarding the notability of Commonswiki categories

Please see "Wikidata:Requests for comment/Allow for Wikidata items to be created that only link to a single Wikimedia Commons category (Wikidata notability discussion)" for a discussion related to the inclusion of Wikidata items whose only (Wikimedia) sitelinks link yo Wikimedia Commons. -- Donald Trung/徵國單  (討論 🀄) (方孔錢 💴) 19:18, 12 February 2019 (UTC)

Photographer property

There has been a discussion of people around Wikimedia Commons' Structured Data about it, but I also see a missing need for such property when describing images here on Wikidata that it's missing. There is an author (P50) and author name string (P2093) for authors of the text, which cannot be used so much (or at least someone was disputing it). So what about to create autor (file) [this, because there are other types of files than photos] and/or photographer property for files/photographs. And something like autor (text, file), photographer (text) for those, who cannot have an item, which in the case of WMC will be a lot of cases. What others think? --Juandev (talk) 01:55, 9 September 2019 (UTC)

Just use author (P50)/author name string (P2093). Thanks. Mike Peel (talk) 06:50, 9 September 2019 (UTC)

I think that is ok, but we need one more property. For authors/photographers they have an Account here we need author/creator property with username datatype. Many images will have these property and author name string (P2093) but I think if we do not say every user is notable or we create a new item-type just for users this is the only way. --GPSLeo (talk) 07:43, 9 September 2019 (UTC)

@Mike Peel: as you wish, if community doesn't block it, why not.

@GPSLeo: If we can use author name string (P2093) where Commons autor could be used as simple text, why we need a new data type for it? --Juandev (talk) 11:05, 9 September 2019 (UTC)

To not only link with the name of the author. To link with the account too. That dose only work as author name string (P2093) is string datatype and can not link and the most usernames are different to the real name used to declare the file as selfmade. --GPSLeo (talk) 20:14, 9 September 2019 (UTC)

TemplateData

Mediawiki TemplateData can be used to translate a template documentation. The worst: you have to copy from a Wikipedia to another Wikipedia, to see the documentation in the destination language.

I have done it in Wikipedia Template:Short description. I have translated the TemplateData from English to Spanish (you can edit TemplateData and select "español" -this is, Spanish- to see the translation into Spanish).

The problem: I have to translate the template documentation (TemplateData of the template) in the English Wikipedia and copy and paste it into the documentation page o f the template in the Spanish Wikipedia.

This is not good. The best idea is that I could see the translation in the Spanish Wikipedia, without copy and paste, in a Wikidata manner (global documentation from TemplateData).

Also, this translation into Spanish could be seen in Wikibooks in Spanish, Wiktionary in Spanish and so on, without copy and paste the TemplateData from the English Wikipedia to Wikibooks in Spanish, Wiktionary in Spanish and so on. --BoldLuis (talk) 10:56, 15 March 2021 (UTC)