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(a)googlemail.com>wrote;wrote:
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(a)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(a)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(a)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(a)lists.wikimedia.org
>
https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<
______________________________**_________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<
https://lists.wikimedia.org/mailman/listinfo/wikitech-l>
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
undefined
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l