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
