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 < [email protected]> 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 <[email protected] > >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 <[email protected]> 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 > >> [email protected] > >> https://lists.wikimedia.org/**mailman/listinfo/wikitech-l< > https://lists.wikimedia.org/mailman/listinfo/wikitech-l> > >> > >> > > > > ______________________________**_________________ > > Wikitech-l mailing list > > [email protected] > > https://lists.wikimedia.org/**mailman/listinfo/wikitech-l< > https://lists.wikimedia.org/mailman/listinfo/wikitech-l> > > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- undefined _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
