Commons talk:Structured data/Get involved/Feedback requests/Statements

The following discussion is archived. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Thank you all for participating and leaving your feedback, thoughts, and questions. There will be a clickable prototype based on your feedback to these designs in the near future. Keegan (WMF) (talk) 17:17, 9 October 2018 (UTC)

---

Primary questions: does the license statement design work for you?  Is it intuitive in its environment? Is there anything missing?

Secondary questions: If the current file page was replaced with this tomorrow, is this something you could work with? Do you know what all the information means, and how to use and edit it? Please keep in mind that the information in the current file page will remain, and will remain exactly the same.

Please share your thoughts. Keegan (WMF) (talk) 15:06, 6 September 2018 (UTC)

Relation to Wikidata?

• I guess I'm trying to wrap my head around the "on Commons" bit. Does this interact with P18 on WD at all? Does this make any other difference on the WD side at all? GMG^talk 16:13, 6 September 2018 (UTC)

not much. Every single file on commons, will have its item on wikidata, but they will be in different ns--Juandev (talk) 03:17, 9 September 2018 (UTC)

• • Point of clarification: Commons will soon have its own instance of Wikibase, which is the same system that drives Wikidata. However, being a separate instance, it'll have its own database. You can think of it as Commons soon having M items for each file (stored in the Commons Wikibase instance) while Wikidata will still have its separate Q items and properties (the Commons Wikibase instance will use Wikidata properties). RIsler (WMF) (talk) 22:42, 10 September 2018 (UTC)
    • Ooohkay. That's makes more sense. GMG^talk 00:13, 11 September 2018 (UTC)

• RIsler (WMF): The Commons Wikibase instance will need to have its own properties. Typically for licensing issues (and certainly others), which are out of scope in Wikidata. See my failed proposal about this in Wikidata: d:Wikidata:Property proposal/copyright status. Regards, Yann (talk) 10:34, 11 September 2018 (UTC)

• Hello,Yann. The Wikidata (WMDE) team feel confident that the two communities (Commons and Wikidata) can hash this out and house the information on Wikidata once we settle on a model for Structured Licenses. Additionally, there are some technical limitations with the current implementation of Wikibase federation that prevent Wikibase@Commons having its own properties. We're keeping an eye on how this develops, and if the communities can't reach consensus we'll explore other options. RIsler (WMF) (talk) 20:49, 11 September 2018 (UTC)

• RIsler (WMF): It seems there is quite a misunderstanding about this. It should be made clearer as soon as possible. See d:Property talk:P275#Rename and extend. Regards, Yann (talk) 06:04, 12 September 2018 (UTC)

• Thank you for your efforts, Yann. The team is aware of the problem of misunderstanding, and we're working on a plan for it. Keegan (WMF) (talk) 18:52, 13 September 2018 (UTC)

Layout

• Let start by saying that I really like this layout and look forward to see it implemented. A few points:
  • One thing I don't quite understand: There is what looks like a tab "Metadata" and a section "Metadata". What is the difference? Or does the "tab" just scroll to the section?
  • Currently the metadata section looks to be quite long, especially if more statements are added in the future. I feel that too much information is visible by default. For example, do we really need five additional lines below a license that list the usage rights open at all times? Maybe it would be better to only shows this additional information when someone clicks a "details" link next to a statements, or something similar.
  • Personally, I'd prefer categories to be at the very bottom of the page, not in the existing file page tab.
  • Similarly, while you are introducing tabs, I'd prefer to have the "user content" part (i.e. everything entered as wiki) text and the existing meta data (versions, usage information etc.) on a separate tab. I believe this would allow faster access to that information and make the page more structured. Currently, you have to scroll to find the meta information and the scroll amount depends on the amount of user-entered information.
• Sebari – aka Srittau (talk) 17:58, 7 September 2018 (UTC)

• The "tab" scrolls to the metadata section, that is its function. Thank you for the rest of the feedback. Keegan (WMF) (talk) 22:36, 10 September 2018 (UTC)

Infobox

Why is there a public domain icon and disclaimer in the blue infobox next to the image when the original licence is GFDL and multiple CCs? De728631 (talk) 16:01, 6 September 2018 (UTC)

The infobox is a placeholder graphic so that you can see the whole page together. The text inside is not to be taken to literally match the image, as it is meant for reuse from one mockup to another. Keegan (WMF) (talk) 18:21, 6 September 2018 (UTC)

I came her to ask the same thing :) It was so confusing, for a minute I thought the lower license was for the graphics on the plane. Ainali (talk) 21:30, 7 September 2018 (UTC)

I also found the placeholder infobox quite confusing. I think realistic examples would be more useful, if we are going to figure out if this interface makes sense. --Jarekt (talk) 01:04, 8 September 2018 (UTC)

I'll ask about getting design changes to have the license in the infobox reflect the file page being represented - I'm not sure if I will be successful or not. I will update the page if I can get new mockups. Keegan (WMF) (talk) 20:19, 10 September 2018 (UTC)

I won't be able to get a mockup with matching licenses this time, but it's something that will be fixed by the next community review. Keegan (WMF) (talk) 16:04, 12 September 2018 (UTC)

Presentation

Pages will be very long -- should CommonsData statements be on a separate tab?

I'm curious as to what are the key advantages the team sees in having everything presented together on a single very long monolithic page? What would be the pros and cons of alternatively presenting the CommonsData statements as a separate tab?

Second question: where would category information go? At the moment it is always comparatively easy to find and edit with HotCat, simply by going to the end of the page. In the new design, will it still be at the end of the (now massively long) page, where perhaps rather few people will see it? Or will it be adrift somewhere in the middle of the page, at the end of the wikitext section? Jheald (talk) 18:56, 6 September 2018 (UTC)

Categories will still be at the bottom of the page, I believe. Keegan (WMF) (talk) 17:26, 10 September 2018 (UTC)

Definitely the lenght of the page might be a problem and cats manipulation also. There are more ways how to fix it. One is to move data to a separate tab, the other is kind of drop down menus.--Juandev (talk) 09:03, 9 September 2018 (UTC)

I agree with the worries about the length of the page. I'll pass the shared concerns along. Keegan (WMF) (talk) 17:26, 10 September 2018 (UTC)

I asked what the team's views were about the pros and cons of presenting the CommonsData statements as a separate tab.

I hoped that would start discussion on the issue. But ... silence ... no comment forthcoming as to why the CommonsData statements have been placed on the same page, why the team thought this was a good design decision.

I can suspect what an answer might be -- that if the CommonsData statements are on a tab that has to be clicked on to be visible, then most users won't see it, so much of the team's efforts would be ignored, or at least unseen.

But perhaps CommonsData statements shouldn't be immediately visible to naive users -- see eg the discussion about licensing information and licensing templates immediately below. For some time, the CommonsData statements on licensing will be less complete and less reliable than existing licensing templates; and they will always be less informative. It would therefore be entirely a good thing if they were banished from the main information tab, so the raw statements (when they are available) do not distract from the more authoritative and more complete user-directed templates mediating their content. Jheald (talk) 16:31, 4 October 2018 (UTC)

Different design to Wikidata?

Also: what are the reasons for the change of design of CommonsData statements compared to the established Wikidata interface? What are the perceived pros and cons that have motivated the different presentation? Jheald (talk) 18:56, 6 September 2018 (UTC)

The Wikidata presentation is a nothing more than the most basic widget set you can come up with to structure unlimited information. In a more limited usecase, targeted at an audience that might be less experienced with data structuring, you can create more focused interfaces, because you know WHAT and WHERE you will be presenting it. It can have knowledge that when presenting a license, it should show related information to that license, because it knows that this particular statement is about a license. Because Commons has a limited domain, you can create domain specific widgets. Also I wouldn't expect the Wikidata interface to keep looking the way it does. It works, but it can be much more efficient, and I expect it will and those changes will likely come from both wikidata and the commons structured data projects. —TheDJ (talk • contribs) 12:58, 9 September 2018 (UTC)

Nevertheless it would be useful to have the team talk about why they want to make these changes.

For example: contrasted with Wikidata, the new design doesn't show a 'deprecated' status, and it doesn't show reference information. So how to say that Source A or Museum B identifies this as a portrait depicting X, but that assessment has been overturned by more recent scholarship?

Or that copyright has claimed by Getty Images, but the Commons community believes that claim has no basis (with a reference to the Commons discussion?)

More generally, while CommonsData can have a different interface, does it make sense for CommonsData to have a different interface, when relevant information is going to be spread so broadly between the two wikibases? Jheald (talk) 16:06, 4 October 2018 (UTC)

Licensing templates?

Further Q -- how does the team see the role of licensing templates alongside CommonsData licensing statements? Does the team see them remaining, or being replaced? Will they be considered to be redundant, or giving the community the chance to spell out the implications, background, and/or legal background of licensing requirements to users, in ways that the community can also readily edit? If they remain, to what extent would the encapsulate and draw from the CommonsData statements, or alternatively to what extent would there be information in one form not fully presentable or representable in the other? Jheald (talk) 18:56, 6 September 2018 (UTC)

Thus it have a sence to have them twice? In template and in Base? Or you are affraid of a hard way to edit them if they are in Base. Here I am pointing out some values of infobox templates on Wikipedia, which are hardly editable from within Wikipedia itself, because, they are mirrored from Wikidata.--Juandev (talk) 09:06, 9 September 2018 (UTC)

The metadata is drawn from the licensing templates and/or Q item information. There are no plans to remove or do anything with the current template system, and cannot speculate on their future role because we have no idea what it will be. Keegan (WMF) (talk) 17:33, 10 September 2018 (UTC)

Okay, let me give my view then. Licensing templates need to remain the primary, definitive, and required form of user-facing licensing information about files. Fine for them to draw on structured data where available, but structured data will not replace the information they convey in a user-facing role, and would be best not to be visible on the primary tab. In the medium term, the information in the structured data is likely to be considerably incomplete (hit-and-miss at best), so not reliable as a definitive source of information. Even in the longer term, structured data will not replace the kind of detailed explanation given to users in a template like {{PD-US-unpublished}} -- templates need to remain the primary form of information about licensing presented to human users, and the primary place human users expect to find it. Jheald (talk) 16:18, 4 October 2018 (UTC)

Data design for licensing data

It looks to me as if there is a potentially nasty problem with the statement-qualifier design for usage rights statements, particularly e.g with the statuette example.

What if the copyright justification is different in the United States from the EU? -- eg in the United States because the work is pre-1923, but in the EU because it is on permanent display and subject to freedom of panorama, despite the creator still having been alive 70 years before today. In such a case, how is it proposed to indicate which jurisdiction goes with which justification? If they are just qualifiers on depicts, there seems to be no way to untangle which belongs to which.

This also leads to a wider issue about the metadata section: Is it intended just to provide a display and editing environment for the statements held locally on CommonsData? Or is it intended to provide a full representation of the re-use rights pertaining to the image?

E.g., as a second example, consider an image that is a photograph of a museum piece that has its own item on Wikidata (rather than generic "statuette"), one perhaps with non-trivial reuse statuses.

If the metadata section as presented here is intended primarily to show the statements held and editable here locally on CommonsData, does that mean it will show licenses GFDL & CCSA-3.0 applying to the WikiUser's photograph, but not the (hypothetically complex) licensing status of the object itself, because the only CommonsData statement would be "depicts: famous Camel statuette by ZX, wikidata item Q34567890", and would that be all the user would see? That would have the potential to be very very confusing to users, even with strong signposting that the CommonsData statements being presented on the page might only be partially indicative of the full reusage picture. (Also worth noting that where works are in turn depictive or derivative of other works, there might in fact be quite a chain of relative items on Wikidata, with eg different copyright implications in different territories).

I'd also like to add that, even as presented, the usage rights statements on the museum piece example are confusing, and perhaps an updated graphic is needed. According to the current graphic, the image purports to be licensed GFDL by Schacho0822 but CCSA-3.0 by Walters Art Gallery. How are we meant to interpret this? Are the licenses alternatives? Or, does each apply to a different part or different aspect of the image? Or are they cumulative, relating to a sequence of image editing? At the moment, with just the bald statements, this is far from clear; but it does suggest that if there were cases with complex systems of rights, it might be quite hard to work out just what was going on. Jheald (talk) 19:41, 6 September 2018 (UTC)

I echo Jheald's concerns. It appears that a law degree specializing in copyright law may be required to interpret why a public domain designation is only good in one country and not others. Is it feasible to expect volunteers to be qualified to interpret multiple licenses and country restrictions for images, especially considering the respective laws themselves are ambiguous? I have no objection to adding as much information as can reasonably be expected but I'm thinking maybe our legal department should have a look at this, if they haven't already. Atsme 📞 17:41, 7 September 2018 (UTC)

Legal has taken a look at this, and participated in the initial design creation. Keegan (WMF) (talk) 18:00, 7 September 2018 (UTC)

These complications of PD and multi-jurisdiction licenses extends back to the existing file pages where these are sourced from. The complexity of these images is a large part of why they were selected for mockup and review, to raise some of these issues. In the case of attribution/authorship needing to be changed or other problems, editing the content of the metadata will be available. In this way SDC will function like a normal wiki: information is added, it can then be corrected, deleted, expanded, rearranged, or whatever else works best to present the data. In the case of identifying what license or license would be most important or cover the entirety of the file, that is part of the purpose of primary rankings (files can have more than one primary license). When viewing these mockups, think of them as less static things and keep in mind that they will be editable. Keegan (WMF) (talk) 18:12, 7 September 2018 (UTC)

having some training to clarify the license mess, and curate licenses would be a way forward to improve license quality. clearly the current adversive process by self-appointed experts is broken. but that is not a structured data problem, rather the database facilitates the cleanup. Slowking4 § Sander.v.Ginkel's revenge 23:15, 7 September 2018 (UTC)

@Keegan (WMF): Thanks for the response, but editability doesn't help with the issue I'm identifying above -- or if it does help, it would be useful to know how the team believe the statements should look in such a case.

Specifically: if the image subject can be depicted PD in both Europe and the United States, but for different reasons in each jurisdiction -- what is the data design the team is proposing for this case? Simply adding both justifications and both jurisdictions all as qualifiers to the same statement fails, because it is not possible to distinguish which jurisdiction-qualifier pairs with which justification-qualifier. If the team has an approach in mind for a case like this, it would be useful to see it presented as a mockup, to show how the design would cope with a case of actual complexity.

Second: you write In the case of identifying what license or license would be most important or cover the entirety of the file, that is part of the purpose of primary rankings. If this is indeed the case, this would be a hugely significant part of the data design, and really it ought to be flagged up more prominently, and have a mockup illustrating it as a master-statement in action. A particularly interesting case might be where the licences for both the photograph and the underlying object (or series of objects) have attribution requirements; but those for the underlying object(s) exist either a Wikidata item or another Commons file. It really would be useful to see how the team are considering a case like this would be presented; and as an aspect of that the issue I raised above, as to whether the presentation on the Commons page is intended just to provide a display and editing environment for the statements held locally on CommonsData, or whether it is intended to provide a full representation of the re-use rights pertaining to the image.

Third, picking up User:Atsme's comment and your response: Yes, anyone who hangs around Commons for any length of time will surely discover that the nest of rights and justifications and licences and jurisdictions around a particular image can get pretty complex; and that if Commons wants to make that image available for re-use, a necessary part of our job here is to communicate that rights position as accurately, and intelligibly, as we can. Is it feasible to be able to expect volunteers to be able to do that? Actually, yes, it is: I think the Commons community as a whole has developed an exemplary demonstrable capability for getting to the bottom of that complexity, and creating the materials for education and reference to instill in the community just that capacity. But a concern which I do have is that a huge part of that education and building-up of understanding is delivered through the extensive informative text that the community has written into the copyright justification / licensing / rights / requirement templates, that the terse CommonsData statements written for machine consumption will simply not replicate. Hence my question above as to how far these templates will continue to exist alongside CommonsData statements, and whether (or how tightly) they will be interlocked. I do think this is quite an important thing for the community to know the team's current thinking about.

@Keegan (WMF): I do appreciate your responding above in this thread. However at the same time, I believe there are a number of questions that I raised, such as the very issue of the future place of the current Commons licensing and justification templates, that you have not yet given any steer on. Similarly, I see you have now closed the recent discussion on the depicts statement without there having been any team comment or response on a number of areas I raised where I thought there were issues that would be useful to understand and probe the team's thinking and the reasons behind it in greater detail, where a degree of discussion might have been quite valuable (at least IMO). It's okay to say that you're going to need time to formulate a response, or that you need to refer back and consult with more of the team. But if you solicit input on a topic, and people take time to try to think over the horizon and identify questions that they would like to see response and deeper analysis of, that input deserves some corresponding thought and response. It's not okay just to leave it hanging there, unacknowleged and unengaged with and ultimately ignored. If you're not prepared to engage with the discussions people want to have, then don't waste their time by pretending to seek their thoughts. Jheald (talk) 00:18, 8 September 2018 (UTC)

I can appreciate your perspective, Jheald. Honestly, many of your questions are un-aswerable by myself or the development team. For example, what is the future place of current templates? I don't know. There's no plans to change anything that currently exists in the file information, and it would be wrong of me to speculate for the future. You raise many other questions about how things will function in process and practice - the answer to that is that I don't know, because the answer most of the time is "that's for the community to decide." Which I thinks gets to a point: I think many of your questions are best directed towards others here on Commons, so that the community can work together to make the answers. I cannot provide most of them, unfortunately, and it can be a challenge to identify what specific questions from you to the team can be nailed down to answer. Perhaps we can work on breaking apart observations, things for the community, and questions for the developers? Those things seem to often get jumbled and wind up overlooked. Keegan (WMF) (talk) 16:51, 10 September 2018 (UTC)

Okay then, some specific issues:

• When different justifications apply to different jurisdictions, how is it proposed to represent this? The design presented on the page fails to show how the reusability/licensing can be tied to the justification, to cover the case when reusabilty is the result of different justifications in different jurisdictions. It is not enough to say "the information will be editable" -- what is being asked is how could that information be recorded, in the current structure you are proposing?
• Secondly, can we explictly see how is the team proposing to model the case when significant rights information is recorded in an item on Wikidata ? -- or perhaps at the end of a chain of several items on Wikidata. In a case like that, what are you proposing the information of the CommonsData tab should look like, and what interlocks are required? It's not sufficient to say that "this needs to be directed to the community". You the team are proposing a design for rights information, so you the team should be able to come back with how you envision this case should be presented, in your design. Jheald (talk) 16:59, 4 October 2018 (UTC)

• I too think it's worth clarifying with country-specific granularity when needed. Like even giving the caveat that the license is based on the country of origin + United States has an educative effect that licensing law differs between jurisdictions. (Thinking specifically of photos of artwork in freedom of panorama cases here.)

Also worth delving a little deeper on the helper text that accompanies the main listed license, as it will be, for many readers, their only prompt for considering the author's rights. PD is the simplest example but I'd be interested in seeing a CC license mock-up, as it might make more sense to move the "required attribution" field closer to the explanation of how the license works (similar to how the "required attribution" in our current CC template is in bigger text for emphasis). Otherwise many users are accustomed to simply pilfering images from Google Images, and we could educate around that practice by indicating that some images are free for use in presentations and promotional materials as long as their authors are acknowledged in the listed way. czar 11:20, 8 September 2018 (UTC)

Multiple licences

I think it would be helpful for non-experts to clearly indicate which licenses apply to the photo and which apply to the item depicted. - PKM (talk) 20:41, 7 September 2018 (UTC)

yes, for 3D objects, we want a CC photo of the object, for some jurisdictions, i.e. c:File:Kiepenkerl - Jeff Koons.JPG (like your case 2 but more arcane US license) -- Slowking4 § Sander.v.Ginkel's revenge 23:08, 7 September 2018 (UTC)

• That was my comment too. For photographs of potentially copyrighted objects we use {{Art photo}} template which allows to delineate which license relates to which part, see for example File:Egypte_louvre_085.jpg. --Jarekt (talk) 00:59, 8 September 2018 (UTC)
• Agreed. And on a slightly different point, I would think that a new user would be confused by the sight of multiple licenses—worth clarifying when the user can choose can choose any of the listed licenses (as in the poképlane example). czar 11:09, 8 September 2018 (UTC)

• Thanks, folks. I'll pass this along. Keegan (WMF) (talk) 17:16, 10 September 2018 (UTC)

Tangential

I think this is going off on a tangent from the main project. You seem to be asking about the data structure here, which is an already-solved problem through Wikidata (i.e., you can provide the basic tools, with support for properties and qualifiers, and the community can develop the rest). Having said that, the interface here seems to be somewhat different from that currently in use on Wikidata, for reasons that I don't understand - perhaps propose it as a new format for Wikidata to adopt, and then use it here? Thanks. Mike Peel (talk) 01:42, 8 September 2018 (UTC)

• Agreed.
  1. I don't see why there don't seem to be references while templates like Template:Artwork even have a parameter and field to insert<references /> (called references).
  2. And why is there a over-sized "Make primary" button (double the size of the probably more useful "Edit" button and unlike that repeated for every statement) instead of the well-established ranks?

The community can well decide if and how to use these functionality, no need to restrict Wikibase from technical side IMHO! --Marsupium (talk) 09:09, 9 September 2018 (UTC)

Mix

I would not mix license statements with cotent parameters, at this time depicts. Could the information about the stattue lucense stay in the box with license only?--Juandev (talk) 08:03, 8 September 2018 (UTC)

Pink box

The pink area in the mockup is supposed to include the current Commons file page contents. Is that meant to be a transclusion of the wikitext (usually: summary, license, and categories) or also all that is currently transcluded from elsewhere? I mean the following:

Size of this preview: 800 × 533 pixels. Other resolutions: 320 × 213 pixels | 640 × 427 pixels | 1,024 × 683 pixels | 1,280 × 853 pixels | 3,888 × 2,592 pixels.
Add a note
Original file ‎(3,888 × 2,592 pixels, file size: 4.99 MB, MIME type: image/jpeg); (⟳ request rotation); ZoomViewer: flash/no flash
Open in Media Viewer

-- Tuválkin ✉ ✇ 00:41, 9 September 2018 (UTC)

@Tuvalkin: Note that large parts of what you refer to here, are actually gadgets. We can move them wherever we want ourselves. —TheDJ (talk • contribs) 13:14, 9 September 2018 (UTC)

• Sure we can, but if we don’t have to it will be much simpler. -- Tuválkin ✉ ✇ 17:20, 9 September 2018 (UTC)

• I'll find out what the (non-gadget) plans are. Keegan (WMF) (talk) 22:33, 10 September 2018 (UTC)

Usage Justification - mixed use

The use of Usage Justification in the depicts box as de Minis, FOP is ok though it feels like a redundant statement, an over cautious statment and at worse an impass/barrier to contributions from those who just want to share their photos know they can but have no idea of nuances eu,us,au, and martian copyright laws. I also think that that reversing the process when they reuse is going to encourage the ostrich in the room with either sticking their head in the sand or run like hell away from Commons.

Yet the confusion doesnt end there, next box we have usage rights, this again uses the term Usage Justification and says own work, in the alternative example it says OTRS, neither of which provide any clarity nor make much sense in the way its being presented. Problems;

1. usage rights could be more clear and say "copyright licensing" or even "terms of use" both of which at least imply conditions as well as permissions.
2. OTRS - is meaningless by itself even OTRS ticket number 090918999999 doesnt add anything to the understanding of why.
3. Usage Justification - does that mean when it says own work the person using the image can say its their own work as well, because thats exactly what I reading step by step first up share alike then I'll see ownuse go woohoo grab the image and use it possibly even call it my own. Forget author, attribution and link I'll never read those much actually read what they say.

What I think is that with the description being immediately under the image all ready, the first field they should encounter is

Terms of Use currently called usage rights

copyright license: cc-by-sa

reuse: Creative Commons with Attribution, Share a like, unported

Author:Sir Blah Foo

Source: uploaded by Sir Blah Foo, or for OTRS permission received from Sir Blah Foo estate refer to WMF for OTRS ticket 090918999999"

Attribution: Sir Blah Foo photographs

Attribution Link

Then follow with the depicts statement which could include any necessary justifications, plus it could also contain the ALT caption. Gnangarra 02:43, 9 September 2018 (UTC)

Copyright with logo

The actuall practise with copyrighted images is too leave thanks to the donator and its logo. It is done by a special template. How this will be integrated?--Juandev (talk) 03:10, 9 September 2018 (UTC)

@Juandev: You should provide a link, so that everyone knows 1. what it is you are talking about and 2. we are all talking about the same thing instead of making assumptions. —TheDJ (talk • contribs) 13:06, 9 September 2018 (UTC)

• I think know what Juandev is refering to here: Special templates, namely about GLAM donations, that are added usually under the Permissions heading. -- Tuválkin ✉ ✇ 17:19, 9 September 2018 (UTC)

• An example would be helpful so that I can be precise, yes. I believe Tuválkin is correct, but I want to be sure. Keegan (WMF) (talk) 17:21, 10 September 2018 (UTC)

• Yup I am talking about GLAM cooperation. Eg. this: Template:BNF cooperation project.--Juandev (talk) 15:55, 12 September 2018 (UTC)

Translation

Regarding the second question, if you deploycsuch design tommorrow, it would be nice to have all the messages translsted as we dont understand some terms.--Juandev (talk) 03:14, 9 September 2018 (UTC)

• Absolutely, all messages will go through translatewiki before deployment. Keegan (WMF) (talk) 17:25, 10 September 2018 (UTC)

Feedback

Primary question

Yes, mostly. I would like to be able to fold away the whole obligations/justification/Author stuff. It would also be nice to have the primary on top regardless of the order in which the data has been introduced.

Secondary question

It's complicated. These seem straightforward for experienced users, but all that data might be even more confusing for newcomers. For instance, what does "de minimis" mean? How can one find out? The same for attribution (can you attribute just by username or you have to mention the site etc.), share alike (what's "alike"?), own work. I know these are not necessarely covered in the current layout either, but at least there are links one can use to read more.--Strainu (talk) 12:47, 11 September 2018 (UTC)

Public domain

In the examples, I see nothing addressing why a particular file or depicted work of art is in the public domain. Am I missing something, or is this not there? There's a big difference between (for example) being in the public domain because the author died before a particular date, being in the public domain because a U.S. copyright was not registered (or not renewed), and being in the public domain because a logo (for example) is too simple to be copyrightable in the relevant country. - Jmabel ! talk 23:50, 20 September 2018 (UTC)

Good point, thank you. Keegan (WMF) (talk) 17:53, 24 September 2018 (UTC)

Prominent "Uploader" on box and attribution

While in many cases the uploader is the same as the author or the copyright holder, that is not true in many other cases: bots uploading entire donated collections, photos taken from public domain sources, authorizations given, etc. While the metadata content will make this clear, separating the physical author from the copyright holder and from the actual uploader, we should not give prominence to the uploader above the other too, specially the copyright holder, and we most definitely should not encourage to attribute the uploader.

For example, let's say there is a photographer that works for a famous tv show, and the tv show that contracted the photographer gave us permission to upload their catalogue. There is 3 different entities here: the Author, which is not the copyright holder, and should be mentioned but it is not the rights holder-, the tv show producer, which holds the rights, and a bot to upload the photographs "tvshowbot". We should not encourage to attribute "tvshowbot", but "tv show/tv show producer/network", which was the entity that did the donation and will want to be credited. Wikimedia mention can be kept in addition, as normally there maybe edits or improvements by the community, and it is a shortcut to where to find more information. While mediawiki only keeps metadata at the moment of the uploader, copyright holder should be sourced from the appropriate wikibase field, or skip altogether and only keep a link to check below the copyright information. --62.14.93.92 11:48, 23 September 2018 (UTC)

• Also, on licenses that allow specification of attribution, it may be different from all of these. - Jmabel ! talk 16:08, 23 September 2018 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.