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

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 the feedback. Everything has been read and taken in, I will keep you posted about how we develop the feature further based on your input. Keegan (WMF) (talk) 18:58, 21 November 2018 (UTC)

---

Questions from the developers

If you have your own observations or questions, please do leave those as well

Does this cover all reasonable cases you can think of?

If not, please offer some examples files or Q items where this wouldn’t work. Extreme edge cases should be considered but not necessarily required.

Do you want Structured Data to replace current license systems, or just supplement them?

The original idea was to add structured data to improve the machine-readable use case for algorithms and bots (search, analysis, etc.). In the previous consultation there was some concern about ease of readability/explanation for ordinary humans. Is this a requirement, since we already have human-readable templates in place?

If this doesn’t work for you, how would you like it to work?

Specific counter-proposals are welcome and encouraged. Keegan (WMF) (talk) 22:37, 1 November 2018 (UTC)

Wikidata items

Unrelated to the above questions (which I probably don't know how to answer), I think it might be worthwhile to ask some other Wikidata contributors about whether it's okay to represent Commons templates as "rights statement codes", since I'm not sure how logically valid this would be. I think it's possible and could make sense, but it could be less complicated to not directly involve the items about templates.

If the templates are being used to directly identify "usage justifications" then it might be sensible to either have a separate group of items for the reasons themselves (e.g. "considered de minimis") which are linked with another property to the respective items about the templates, or have the Wikidata property for this information be about the templates rather than the reasons (e.g. "Commons template used for justifying copyright situation"). Jc86035 (talk) 16:44, 2 November 2018 (UTC)

Quote each authors below each "own work"

For File:Full page mockup of svg file page.png. The full attribution text at the end is good. But in addition, maybe that each depict statements that has "own work" as usage justification should also have an author field. Because each depicted things (can) have here a different author.

Example for only one depicted thing:

ribosome

Usage right - cc-by-sa-2.5

Usage ustification - own work

Author - Jerome Walker

Christian Ferrer ^(talk) 20:19, 2 November 2018 (UTC)

and in case that there are several ribosomes coming from different sources, then for the understanding we should have the source too:

ribosome

Source:File:Ribosme symbol.svg

Usage right - cc-by-sa-2.5

Usage ustification - own work

Author - Jerome Walker

Source:File:TRAP methodology 2.svg

Usage right - cc-by-sa-3.0

Usage ustification - own work

Author - Akiyao

Christian Ferrer ^(talk) 06:57, 3 November 2018 (UTC)

Usage rights

Have you talked to your legal team about this? In particular our licenses don't really cover, trademark, personality rights, moral rights (technically Artist's Resale Rights) and various weird things under the DMCA and napoleonic code countries in general.Geni (talk) 01:44, 3 November 2018 (UTC)

Yes, we've talked to the Legal department. The first round of designs were heavily influenced by Legal. Keegan (WMF) (talk) 18:22, 5 November 2018 (UTC)

How can you tackle the problem of pictures or videos of public places in countries without freedom of panorama? Here (e.g. Russia or Ukraine) no tourist has a rasonable way to ensure, whether an outdoor photo contains prohibited items. An example may be the wikimedia item [[1]] depicting the statue "Mother Homeland" in Kyiv. It was deleted from wikimedia out of this reason. An illegal copy has (so far)remained in the German wikipedia [[2]]. In such cases "de minimis" cannot be argued.

G-u-t (talk) 19:15, 11 November 2018 (UTC)

New example: Timeline

The "depicts" term assumes that the derivative work includes the original image. This isn't aways the case. For example File:Making the Modern World gallery london science museum.JPG is a derivative of File:Science Museum - Transportation area.jpg.Geni (talk) 01:47, 3 November 2018 (UTC)

Hi, It is the other way round: File:Science Museum - Transportation area.jpg is a derivative of File:Making the Modern World gallery london science museum.JPG. Yann (talk) 05:39, 14 November 2018 (UTC)

Annotations replacement

It would be useful if the "depicts" property took a qualifier which gave the exact position of the thing being depicted. This could potentially replace the usefulness of Gadget-ImageAnnotator. ~★ nmaia ^d 01:04, 4 November 2018 (UTC)

@NMaia: Have a look at relative position within image (P2677)! --Marsupium (talk) 13:54, 4 November 2018 (UTC)

@Marsupium: Thanks, that's perfect! ~★ nmaia ^d 17:41, 4 November 2018 (UTC)

question about multistream media

What happens when we have a video and the licence for video portion is different from audio? What if there are multiple audio streams with different authors/licences? ℺ Gone Postal (〠 ✉ • ✍ ⏿) 09:13, 5 November 2018 (UTC)

We have some initial ideas on this, but we'd like to start with ideas from the Community since this is a question of curation. Do you have any ideas for how you'd like to see that modeled? RIsler (WMF) (talk) 18:14, 6 November 2018 (UTC)

Can we have requested use on licences?

I see that working as something along the lines of browser HTTP request, where the browser sends the list of languages that the person wants to receive and marks them with a weight 0.0 - 1.0. The server is still free to serve whatever version it wants to it knows that the user would prefer a specific version. Same here. For example, I provide FAL, GFDL, CC-SA for my original uploads, but the first licence is what I would politely ask my reusers to distribute their modified versions as, knowing full well that they are free to chose any or all of the licences. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 09:16, 5 November 2018 (UTC)

I can't speak for the feasibility or possibility of developing this feature for structured data, but I do think the purpose of rankings for marking primary in the mockups is the same general purpose as what you're saying. Additionally, if/when the team gets to working on attribution generation next year, it will serve a similar function. Neither way will be as direct as what you're describing, but it still leaves things in community control. Keegan (WMF) (talk) 19:20, 5 November 2018 (UTC)

Obligations qualifier

It appears that "Obligations" is established as a qualifier here? If so, I'm not sure what the purpose is. Presumably, the items for the licenses themselves would include the obligations there. Is it possible for usage obligations to differ even when using the same license? Or perhaps it's not actually a qualifier, but some extra display text taken directly from the license item but not editable per item on its own? --Yair rand (talk) 03:24, 6 November 2018 (UTC)

Agree, I was wondering as well. Those obligation aspects are a question of presentation. Presentation and data should be separated, I think we will create templates reading the data and then present those obligation in a way similar to current templates just with the data underlying being structured and not wikitext. --Marsupium (talk) 17:17, 6 November 2018 (UTC)

"De minimis"

I'm rather uneasy about the chosen examples featuring "depicts" statements with usage justification "de minimis".

If something is really "de minimis" it should be so incidental to the image as to be not worth mentioning -- and certainly not something worth calling out as an indexing tag for the image. If a thing is sufficiently prominent to note in a depicts statement, then by that very fact it is not "de minimis".

It would seem a bit mad if we couldn't show images of the plane with the Pokemon livery, but I'm not sure what the legally correct justification should be here. "Implied licence" seems to me perhaps the most plausible, but I am not sure whether that is a justification Commons officially accepts. Jheald (talk) 08:42, 6 November 2018 (UTC)

So far, it seems that Commonists are okay with this. In our previous licensing discussion we used Louvre at Dusk as an example (an image with a copyrighted structure right in the middle of it, but deemed de minimis by the community despite a nomination for deletion). Somewhat surprisingly, no one raised concerns about it. RIsler (WMF) (talk) 18:43, 6 November 2018 (UTC)

The Louvre Pyramid issue is covered by the Terreaux case (see explanation [3]), which is quite a different argument than the usual de minimis case. Basically the Court said that we can't avoid taking the pyramid while taking a picture of the whole place. Regards, Yann (talk) 05:49, 14 November 2018 (UTC)

Why does it look different from Wikidata ?

According to the FAQ section, We have the opportunity to make the design fit the specific use cases of Commons.

Okay, but how does one show that a statement is deprecated, or show a reference for it? (Something that external users, eg on the IIIF discussion list, have specifically noted that they want, eg for building IIIF manifests for images and groups of images including sourced annotations). Jheald (talk) 08:49, 6 November 2018 (UTC)

Agree, see Commons talk:Structured data/Get involved/Feedback requests/Statements#Tangential. It doesn't make things easier for users to use two unnecessarily different UIs, also for editors and depending on its design also for scripts interacting with the CSS. --Marsupium (talk) 17:14, 6 November 2018 (UTC), 17:26, 6 November 2018 (UTC)

Thanks for the feedback. Could you point to the IIIF discussions you mentioned? In general, what we're trying to do is discover if default Wikibase behavior is actually optimal for the Commons use case. For the moment, we've purposely left off deprecation and references so that we can explore if there's a better way to do it for a multimedia use case (or if it's even truly necessary). For example, the Make Primary link in our designs was added because of consistent feedback that the ranking arrow button UI in Wikidata is confusing, and the Wikidata use case for it didn't quite fit for multimedia. Deprecation in Wikidata can be inconsistent and confusing too, and at times insufficient because use of "reason for deprecation" isn't strictly enforced. We'd also want to explore if there's a better way to do references. So, for our purposes, the better questions are: What exactly would people like to use deprecation and references for on Commons? What functionality would be optimal for those use cases? It may be the case that what's already in Wikibase is the best we can do, but we do have a useful opportunity to see if there's potential for a better solution (perhaps even one that gets integrated into Wikidata later) and we encourage community members to propose ideas. RIsler (WMF) (talk) 18:03, 6 November 2018 (UTC)

Thank you! Indeed ranks and references have quite some issues. I think though that at least a big part of those issues applies for Wikidata just the same way as they might apply to future Commons situation, thus it seems to be a better idea to solve them at the root, e.g. in the data model of Wikibase and not to fork and reinvent the wheel. Also a lot of consideration has been done about problems and can be found on phabricator, for the visibility of ranks for example phab:T206392, phab:T139081.

Indeed ranks are used inconsistently in their meaning over properties and that's confusing. They are used for two dimensions, for validity in time and for time independent validity, which was pointed out in some other ticket that I can't find right now. But I'm afraid that using another model will only create other problems and then they have to be tackled at two fronts. --Marsupium (talk) 03:48, 7 November 2018 (UTC)

Data modelling for timeline/ collage images

First of all, I'm impressed with the design aspects of these mockups, and the way the project is progressing. It has me very excited for the future. The concern I'd like to raise is about the data modelling implied by the timeline mockup. You represent the file as depicting a chromosome, which has certain usage rights etc. The chromosome doesn't have usage rights: the creative work depicting it does. Properly we should say that the timeline is a derivative work of File:Chromosome.svg (let's say) which has a source, usage rights and so on. We can also say that File:Chromosome.svg and the timeline both depict a chromosome- the thing identified by https://www.wikidata.org/wiki/Q37748 . But that thing depicted is not the thing that has usage rights. A collage does not depict the other art works used to make it; it is a derivative work of them. In Commons, as with any platform which encourages remixing, is a derivative work of is an important property. MartinPoulter (talk) 13:53, 8 November 2018 (UTC)

Thank you for your feedback. We have had similar concerns with modeling the data about a thing vs. modeling the data about the media that depicts the thing. Christian Ferrer above had a different take on it, one that maintains the depicts structure but has additional properties included to make certain distinctions. We're very interested in other perspectives on this issue. If you have the time, it would be quite helpful if you could list out what you think the optimal structured data statements should look like in this case. Thanks. RIsler (WMF) (talk) 16:25, 8 November 2018 (UTC)

RIsler (WMF) , File:Full page mockup of camel file page.png is quite a good representation and likely a good track for derivative works. We have a section file term of use and just above that is interesting, we have two things camel and statuette (with the usage justification). This is a good example because the photo is a derivative work of the statuette. Then apply the same thing to all the potentials objects that make up a derived work, but differentiating each time the object "artwork" and the depicted subject, e.g. a camel and a statuette, or a Chromosome and the file from where comes this Chromosome. In summary in the depict section you should have all the things depicted (of course) e.g. camel, car, chromosome, ect, ect.. + any media or any artwork that is visible or has been used to make the derivative work, e.g. statuette, poster, file, ect. ect.. (with their usage justification). Christian Ferrer ^(talk) 17:28, 8 November 2018 (UTC)

Uploader

Why "uploader" information is highlighted this much in the examples? It is not very important and highlighting it may lead to many incorrect attributions as reusers may try to give credit to the uploader than the author. It happened in the design of Media Viewer earlier and removed later. Jee 14:28, 9 November 2018 (UTC)

Uploder is only important if we do not know anything about authors and suspect that uploder might be an author. Files like that might have uncertain copyrights. Uploader information in the space where we describe licenses and attributions could lead to missattribution described by User:Jkadavoor. For example, years ago I was involved in efforts to remove some watermarks from images which were otherwise unusable. After removal of the watermark I was reuploding them and eversince I am often confused for author of those files. Same thing with people involved in moving files from Wikipedias. --Jarekt (talk) 20:43, 9 November 2018 (UTC)

Thanks, folks. I don't think we've addressed the problem being mentioned here directly on-wiki, but I know we've discussed it and the team is aware of the potential confusion between uploader/author. The design of that box in the top right is not a finalized design, it's a placeholder for something similar that may go there in the future. I do not think the plans are to highlight the uploader there in the final form, that is what was made in the draft design and it hasn't been updated. Keegan (WMF) (talk) 17:50, 19 November 2018 (UTC)

ready-to-copy-paste licence

(preemptive apologies in case this has been addressed before)

Is there, or would it be possible to make, a credit line for potential users that they can simply copy and paste when they use the image? For instance, in the case of the Camel statuette File:Chinese_-_Camel_-_Walters_492383_-_Profile.jpg, nowhere can I see a line "Walters Art Museum, Cc-by-sa-3.0", which is how the work could typically be credited.

Could we have something of the sort displayed prominently?

Cheers! Rama (talk) 11:06, 12 November 2018 (UTC)

• I think this will be still available in the tab "file description", what is show here is the tab "structured data" Christian Ferrer ^(talk) 11:46, 12 November 2018 (UTC)

• Christian is correct. Credit line will still exist in wikitext by our designs, and a later feature release planned for structured data is an attribution generator that will do this in a structured way as well. Keegan (WMF) (talk) 18:01, 15 November 2018 (UTC)

Garbage in garbage out

In the licensing codes there are still many errors. For example I still see cases where old postcards are uploaded as 'own work' and as source 'own collection'. If there is a convertion the license data has to cleaned up first or at least checked.Smiley.toerist (talk) 13:42, 12 November 2018 (UTC)

• I agree that we will need to clean up a lot of bad metadata. It would be nice if we can do it before porting to Structured data; however once it is in Structured data it will be much easier to query and find inconsistencies. Maybe we need some sort of verification flag, where we mark metadata copied "as is" and we would ask people to remove once verified. --Jarekt (talk) 15:40, 12 November 2018 (UTC)

I'm not sure that this needs to be addressed specifically in this context. At least, structured bad metadata still isn't poorer than unstructured bad metadata, and of course people will continue to upload images with wrong information (often out of a lack of copyright knowledge; "I scanned this postcard, so this is my work! It's my very own scan!" ;-) ...). So, correcting wrong licenses is an ongoing, permanent task that will never come to completion. I agree with Jarekt that structured data may make handling of such cases easier, so I don't think "fixing wrong licenses" is a task that should be prioritized before conversion. Gestumblindi (talk) 19:19, 12 November 2018 (UTC)

I agree that we can also do the clean up of bad metadata after the convertion, but some actions dont have to wait and can facilitate the convertion. It would help if we can relialably identify the old post card files. All such files should use the 'postcard' template in the source text.

• One should run and create scripts that convert all mention of 'carte postal', 'briefkaart', 'postal cart', etc into the template in a similar way as the date scripts that convert the diverse imputted date formats.
• In principle if a post card category is used, their should be a 'postcard' template in the source text. However there are exceptions: For example a picture of a post card stand at a tourist shop. In reverse a 'postcard' template in the source text should always require the inclusion of a postcard category.
• Many checklists are posible: 'Post card' in the file description but not in the source, etc.Smiley.toerist (talk) 09:51, 14 November 2018 (UTC)

It would if one old postcard example is used in the projectpage with an postcard editor such as Nels. In wikidata the postcard property would be very usefull in searches.Smiley.toerist (talk) 09:51, 14 November 2018 (UTC)

An typical example of a usefull file needing licence cleanup: File:Lalheue CPA. Vue générale et lavoir.jpg.Smiley.toerist (talk) 09:51, 14 November 2018 (UTC)

In the meantime the cleanup has taken place. Look at the original version of 2 october 2018.Smiley.toerist (talk) 11:48, 14 November 2018 (UTC)

Another example is: File:Concarneau 028 L'arrière-port et le quai d'Aiguillon dans les premières années du XXème siècle.JPGSmiley.toerist (talk) 11:52, 17 November 2018 (UTC)

---

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