Dan Nessett wrote: > The discussion about whether to support license data in the database has > settled down. There seems to be some support. So, I think the next step > is to determine the best technical approach. Below I provide a strawman > proposal. Note that this is only to foster discussion on technical > requirements and approaches. I have nothing invested in the strawman. > > Implementation location: In an extension > > Permissions: include two new permissions - 1) addlicensedata, and 2) > modifylicensedata. These are pretty self-explanatory. Sites that wish to > give all users the ability to provide and modify licensing data would > assign these permissions to everyone. Sites that wish to allow all users > to add licensing data, but restrict those who are allowed to modify it, > would give the first permission to everyone and the second to a limited > group. > > Database schema: Add a "licensing" table to the db with the following > columns - 1) revision_or_image, 2) revision_id, 3) image_id, 4) > content_source, 5) license_id, 6) user_id. > > The first three columns identify the revision or image to which the > licensing data is associated.
That's ugly. I would prefer having one licensing table for revisions and another for images (btw, there's no such thing as image_id they are identified by name, or the id of their description page, plus timestamp if you also want to address old versions). > The content_source column is a > string that is a URL or other reference that specifies the source of the > content under license. The license_id identifies the specific license for > the content. The user_id identifies the user that added the licensing > information. The user_id may be useful if a site wishes to allow someone > who added the licensing information to delete or modify it. However, > there are complications with this. Since IP addresses are easily spoofed, > it would mean this entry should only be valid for logged in users. The user id could be stored at the logging table. You may want to add a licensing_id to identify rows on this table. > Add a "license" table with the following columns - 1) license_id, 2) > license_text, 3) license name and 4) license_version. The license_id in > the licensing table references rows in this table. You could begin by hardcoding the available licenses in the extension, and then add support for the license table. There is a number of issues there: When can you remove a license? (maybe never once it is used), which licenses are shown as available? Do you have licenses which will "change" (eg. when you may want to change the default license from "CC-BY-SA 3.0 or later"to "CC-BY-SA 4.0 or later") ? Note that the license_version could also be part of the license_name. To make it useful you probably need a boolean to mark that it is an "or later" licensing. > One complication is when a page or image is reverted, the licensing table > must be modified to reflect the current state. If you are associating licenses with revisions (instead of pages), you don't need to change the state in the licensing table on further edits (just copy the license of the previous revision). > Data manipulation: The extension would use suitable hooks to insert, > modify and render licensing data. Insertion and modification would > probably use a relevant Edit Page or Article Management hook. Rendering > would probably use a Page Rendering Hook. > > Page rendering: You probably don't want to dump licensing data directly > onto a page. Instead, it is preferable to output a short licensing > statement like: > > "Content on this page uses licensed content. For details, see licensing > data." > > The phrase "licensing data" would be a link to a special page that > accesses the licensing table and displays the license data associated > with the page. That's fine. You could even use "Content on this page uses licensed content from XXXX under [[Special:Licenses/YYY|YYY license]]" Do you want to support multilicensing? You could have revisions with data coming from several sources. That means you must allow duplicated revision_id in the licensing table. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
