This looks great. I know a few sites that are already screenscraping for our license info, so this will be a huge help for them. I noticed, however, that the API currently doesn't support the attribution parameter of the licensing templates (where it specifies the attribution string). I'm sure this is just because it's an experimental demo, but thought I would mention it anyway, just in case :)
Ryan Kaldari
On Fri, Sep 6, 2013 at 7:54 AM, Magnus Manske magnusmanske@googlemail.comwrote:
I can offer this demo (quickly ported from toolserver, which now refuses to run it): http://tools.wmflabs.org/magnustools/commonsapi.php
Far from perfect, but to show what could be done now.
If anyone's interested in helping me develop it, I'll make it a "real" tool on Labs.
Cheers, Magnus
On Fri, Sep 6, 2013 at 3:08 PM, Derk-Jan Hartman < d.j.hartman+wmf_ml@gmail.com> wrote:
I'm just throwing some ideas out there, in hope of inspiring you:
Things you might want to consider (at least in the design) of this API/Extension, might be: multi licensing, derivative and/or 'companion' linking (subtitle files, cropping etc, the pictured object) and their copyrights, keeping track of date and country/location of first
publication
vs date/country of authorship and external repository record numbers/uris (Nasa image, OCLC and other IDs)
These are all elements that have proven to be critical elements in information handling (specifically [re-]publishing) of our media, yet are notoriously difficult/challenging to retrieve currently.
Please don't implement all of it, but I think it would be good to
consider
if design choices made would exclude such things, or enable future enhancements to include them.
Also, remember that attribution != author (Especially with CC)
DJ
On Fri, Sep 6, 2013 at 11:42 AM, Daniel Kinzler <daniel@brightbyte.de
wrote:
Hi Brian!
I like the idea of a metadata API very much. Being able to just replace the scraping backend with Wikidata (as proposed) later seems a good
idea. I
see no downside as long as no extra work needs to be done on the
templates
and wikitext, and the API could even be used later to port information
from
templates to wikidata.
The only thing I'm slightly worried about is the data model and representation of the metadata. Swapping one backend for another will
only
work if they are conceptually compatible.
Can you give a brief overview of how you imagine the output of the API would be structured, and what information it would contain?
Also, your original proposal said something about outputting HTML. That confuses me - an API module would return structured data, why would you
use
HTML to represent the metadata? That makes it a lot harder to
process...
-- daniel
Am 04.09.2013 18:55, schrieb Brian Wolff:
On 8/31/13, James Forrester jforrester@wikimedia.org wrote:
However, how much more work would it be to insert it directly into Wikidata right now? I worry about doing the work twice if Wikidata could take
it
now
- presumably the hard work is the reliable screen-scraping, and
building
the tool-chain to extract from this just to port it over to Wikidata
in a
few months' time would be a pity.
Part of this is meant as a hold over, until Wikidata solves the problem in a more flexible way. However, part of it is meant to still work with wikidata. The idea I have is that this api could be used by any wiki (the base part is in core), and then various extensions can extend it. That way we can make extensions (or even core features) relying on this metadata that can work even on wikis without wikidata/or the commons meta extension I started. The basic features of the api would be available for anyone who needed metadata, and it would return the best information available, even if that means only the exif data. It would also mean that getting the metadata would be independent of the backend used to extract/get the metadata. (I would of course still expect wikidata to introduce its own more flexible APIs).
This looks rather fun. For VisualEditor, we'd quite like to be able
to
pull in the description of a media file in the page's language when
it's
inserted into the page, to use as the default caption for images. I
was
assuming we'd have to wait for the port of this data to Wikidata, but this would be hugely helpful ahead of that. :-)
Interesting.
[tangent] One idea that sometimes comes up related to this, is a way of specifying default thumbnail parameters on the image description page. For example, on pdfs, sometimes people want to specify a default page number. Often its proposed to be able to specify a default alt text (although some argue that would be bad for accessibility since alt text should be context dependent). Another use, is sometimes people propose having a sharpen/no-sharpen parameter to control if sharpening of thumbnails should take place (photos should be sharpened, line art should not be. Currently we do it based on file type).
It could be interesting to have a magic word like {{#imageParameters:page=3|**Description|alt=Alt text}} on the image description page, to specify defaults. (Although I imagine the visual editor folks don't like the idea of adding more in-page metadata). [end not entirely fully thought out tangent]
--bawolff
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<
https://lists.wikimedia.org/mailman/listinfo/wikitech-l%3E
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<
https://lists.wikimedia.org/mailman/listinfo/wikitech-l%3E
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- undefined _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l