Making license and author information api accessible
Closed, ResolvedPublic


There are several projects out there, from stockphoto to mwEmbed, that would really benefit from license and author information of images being accessible in some way in the database. (But perhaps also, mediatype [document, image, video, audio] date, artists, location etc)

1: licensekey -> licenseMessage
2: scraping the information from the existing messages.

My idea was to create a seperate table, then introduce some new type of keyword or function, add this to the templates so that the information gets wrapped by this info and then whenever a description page is parsed, update the table with the new values. I think we'd want to continue to use our current license templates, so for that we need to create some key value system, that is probably a bit smarter than the current license template names, or perhaps we can create a table of all license templates that describes the basic nature of a license (pd, attribution required, share alike, cc-0). That would make searching easier, with the multitude of licenses that we have. Preferably, there should be some consistency in keys for licenses among the different wiki projects, that would simplify searching multiple wiki file repo's...

Version: unspecified
Severity: enhancement
See Also:

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz25624.
TheDJ created this task.Via LegacyOct 23 2010, 3:11 PM
bzimport added a comment.Via ConduitOct 27 2010, 8:13 PM

Bryan.TongMinh wrote:

I have been thinking about this, and there are multiple options to indicate the author and license:

  1. Introduce a new parser tag that will indicate the author, license etc. E.g. {{#author:Bryan}}
  2. Create magic to allow extracting certain template parameters and storing them into a database. I'm thinking of course of the parameters of {{Information}}. I believe we discussed this last year in Paris.
  3. Add a special page/dedicated interface for storing and changing the author and license information outside of the page text and get them with a specific parser function into the text.
  4. Install SMW

An argument for 1) and 2) is that they easily fit into our current system. We just need to change the {{Information}} template in 1) to get the data propagated to the database. As for 2) there would be no action required at all (except rerendering all pages).

A point that was previously raised was that license and author data are actually not associated with page text, but with the image itself. Therefore 3) would make sense, as we are linking the meta data to the image and not to the page text. The downside is that we need to migrate from the old to the new system.

I don't know how and if SMW can solve this problem, but I have heart that it can. I don't think though that we will get SMW in the near to middle term future, so 4) can be removed.

An important requirement to think about when implementing this feature is that images can have multiple authors and licenses and that they need to be saved all.
Another point to think about is whether we also want to store source and date. And other properties. We just need to watch out that we are not rewriting SMW for this purpose though.

Krinkle added a comment.Via ConduitOct 29 2010, 12:37 PM

Number 3 sounds good to me aswell. Just like the pagename/filename isn't inside the wikitext. Things like author and license information (and categories too actually, but that's a different story) make sense to be stored seperately.

Advantage of keeping it outside of wikitext is also that history of the page-text will stay cleaner and changing or renaming a license is a lot easier since they'd be stored as id's instead of template links.
I'd guess things like licenses would then be stored in the License:-namespace or in [MediaWiki:License-<id>-descr] and [MediaWiki:License-<id>-content], which may or may not contain a template.

This is also related to the UsabilityInitiative I think. One of their ideas (not sure if it's choosen as "the plan") was to seperate this making it (the license) into a dropdown when editing (just like when uploading it) - and that licences not in the dropdown, can't be used. (ie. need to be added to it - which makes sense)

Krinkle added a comment.Via ConduitDec 7 2010, 3:06 PM

I've been brainstorming a little last weekend for the details of a few things.

Wrote it up here:


bzimport added a comment.Via ConduitJan 14 2011, 8:45 PM

Bryan.TongMinh wrote:

We've been discussing this here in Amsterdam with Krinkle, Roan and me, have made some changes to the page mentioned in comment #3 and are implementing this in the license-work branch.

I'll assign this to myself, but feel free to work on it.

brion added a comment.Via ConduitNov 29 2011, 9:22 PM
  • Bug 24101 has been marked as a duplicate of this bug. ***
Krinkle added a comment.Via ConduitDec 30 2011, 7:32 PM
  • Bug 8298 has been marked as a duplicate of this bug. ***
Anomie added a comment.Via ConduitNov 25 2012, 11:23 PM
  • Bug 42407 has been marked as a duplicate of this bug. ***
JeanFred added a comment.Via ConduitJan 21 2014, 1:36 PM

With the deployment of the CommonsMetadata extension, license and authors are available through the API (though they are not “accessible in some way in the database”). This could be closed as fixed then?

Aklapper added a comment.Via ConduitFeb 26 2014, 4:46 PM

(In reply to Jean-Fred from comment #8)

With the deployment of the CommonsMetadata extension, license and
authors are available through the API (though they are not “accessible in
some way in the database”). This could be closed as fixed then?

Good catch.
Assuming this covers the request and setting WORKSFORME. Please comment/reopen and elaborate what is missing if CommonsMetadata does not cover this request.

Gilles added a project: Multimedia.Via WebDec 4 2014, 9:22 AM
Gilles raised the priority of this task from "Normal" to "Unbreak Now!".Via WebDec 4 2014, 10:11 AM
Gilles moved this task to Done on the Multimedia workboard.
Gilles lowered the priority of this task from "Unbreak Now!" to "Normal".Via ConduitDec 4 2014, 11:20 AM
Mattflaschen changed the task status from "Declined" to "Resolved".Via WebFeb 14 2015, 1:18 AM
Mattflaschen claimed this task.
Mattflaschen placed this task up for grabs.
Mattflaschen set Security to None.
Mattflaschen added a subscriber: Mattflaschen.
Nemo_bis added a comment.EditedVia WebFeb 15 2015, 2:41 PM

This has certainly not been resolved in core.

Josve05a added a subscriber: Josve05a.Via WebMay 13 2015, 8:52 PM

@Nemo_bis is this problem (whatever it was) resolved? If so, can it be removed as a blocker on T87268: Copyright license and attribution issues (tracking)?

Mattflaschen removed a subscriber: Mattflaschen.Via WebMay 14 2015, 4:20 AM
Nemo_bis added a comment.Via WebMay 14 2015, 6:06 AM

@Nemo_bis is this problem (whatever it was) resolved?


If so, can it be removed as a blocker on T87268: Copyright license and attribution issues (tracking)?

No. Blockers stay after being closed; they only need removal if they didn't block/affect the other issue (especially if they're still open).

Ricordisamoa added a subscriber: Ricordisamoa.Via WebSep 1 2015, 6:34 PM
Restricted Application added a subscriber: Matanya. · View Herald TranscriptVia HeraldSep 1 2015, 6:34 PM

Add Comment