For a tool that tries to fill in {{Information}} templates on commons
based on the current, unstructured text, I have it fill in the "Date"
parameter from the EXIF data of the image, if available.
I just thought: How about a new magic word, {{EXIFDATE}}, that would
extract EXIF data from the image? It could be used in {{Information}}
as a default in case no "Date" parameter is provided.
{{EXIFDATE}} would return blank on namespaces other than "Image:", of
course, and for files that have no EXIF data.
There could be {{EXIFTIME}} and {{EXIFTIMEDATE}} as well, but that
would be luxus :-)
Shouldn't be too costly for the parser (on image pages, image data
will be needed anyway).
Anyone opposed? Anyone willing to code? ;-)
Cheers,
Magnus
I like clear threads.
On 8/12/07, Brianna Laugher <brianna.laugher(a)gmail.com> wrote:
> know about Wikipedia, so they ignore the rest. So then the thing to do
> is change the journalists. :)
As Florence mentionned, this has been done, especially in countries where
1) there is a chapter
2) there is a strong figure in one of the projects but no chapter
3) there is both
In short, it takes people on the ground to change the journalists,
it's not something that happens on a top down basis. Most European
press has now learned to address either the chapter/the community
members responsible for press or the Foundation depending on the
nature of the article they want to write. And if not, it should be a
very clear things for the chapters as well as for the Foundation to
direct them to the right people, "on the ground".
> On 12/08/07, Florence Devouard <Anthere9(a)yahoo.com> wrote:
> > What would be real cool would be to try to keep a written state of each
> > project, what is hot, what is working, what is not working, technical
> > wish list, biggest issues, big figures etc.... so that all participants
> > could "follow" what is going on. I know all this is actually available,
> > but only in a very dispersed manner, so not so easy to find out.
>
[snip]
On 8/12/07, Brianna Laugher <brianna.laugher(a)gmail.com> wrote:
> OK here is an idea for Florence. Write a post to foundation-l
> addressing all projects (e.g. enwikipedia, frwikisource). Ask them to
> put together a 'state of the wiki' report, with the things you
> mentioned:
> * progress reports on pages, users, admins, policies
> * success of any special projects like printed material, wikiprojects
> * any special policy or practice that they have developed, that is not
> seen on other projects
> * technical wishlist
> * "perennial debates" - controversies that often come up in the community
>
> Tell them it's optional to submit a report, and they have a month to write it.
>
> If nothing else it would make for seriously interesting reading. :)
> And the Board can just, you know, publish it on the foundation wiki.
> They don't have to do anything else with it. But just having this kind
> of 'official' request may make people think about these kind of
> things.
This is, unfortunately, not a new idea. Quarto [1] lived and died a
beautiful death and was exactly about that. Making sure that all
projects had a place to express themselves, raise their issues, tell
about the state of their project.
So let me try a different approach. Rather than waiting for Florence
to try again something that she and other people have tried before, or
for "the Foundation " to issue a dealdine, why don't you, Brianna,
come up with a "state of commons" that you broadcast across lists and
projects and ask for the same from other projects, just because you're
interested?
I am a fervent believer that top down has its limits, and that a call
from a "fellow community member" might be better heard altogether. My
take being that an "official" request is not always the answer to
everything, on the contrary.
Delphine
[1]http://meta.wikimedia.org/wiki/Wikimedia_Quarto
--
~notafish
La critique, art aisé, se doit d'être constructive. -- Boris Vian in
*Chroniques du menteur*
NB. This address is used for mailing lists. Personal emails sent to
this address will probably get lost.
NB. Cette adresse est utilisée pour les listes de diffusion. Tout
email personnel envoyé à cette adresse sera probablement perdu.
Hello,
First, an anecdote.
I have had on my Google Reader for a while now, a feed from Technorati
which picks up any blog posts with the words 'wikimedia commons'. A
lot of crud comes through, but also a fair number of real bloggers who
use our photos to illustrate their blog posts. And let me say, they
almost always get it wrong. They fail to link. They fail to mention
the license. They fail to mention the author. Probably we are lucky if
they manage to mention the site name.
While I look at all these random blogs, I notice the proliferation of
Flickr plugins...part of Flickr's success, I feel certain, is due to
their API which allows anyone to easily "plug" Flickr into another
application - a blog, a website, facebook, etc. And in multiple ways:
by license, by keyword, by author(or, close enough: uploader). They
also have that
Commons could do this, but first we need to standardise. Anyone who
actually has tried to write a tool to pick up this stuff will know it
is hit and miss.
So, I am not really planning to work on this in any big hurry, but I'm
just saying it for reference and in case anyone else has a particular
interest in it.
The two main problems are keywords and licenses. Uploaders at least
MediaWiki takes care of. :)
first, the easy one: licenses. There is a painful problem at the
moment that we have no way of knowing which templates are license
templates and which ones are not. New ones are created all the time
and old ones may be converted to deletion templates. (ook.)
so, my proposal.
1. ask for new License: namespace to be installed at Commons.
2. move all license templates into the License: namespace.
3. separate any template which conflates license and source, e.g.
"PD-NASA", "GFDL-GeoDB" (or whatever). Anything which is in the public
domain, regardless of how it got there, should have {{License:Public
domain}}. Indicating source by text + template is fine.
Now I am not sure if there is actually a good reason we have license
categories. Is it safe to assume that no one ever searches via
license? If so, is there any extra functionality we gain from having
the category?
If not, we can quit using categories as well as templates to indicate
licenses. If it is useful, we should change all license categories to
be prefixed with License:. So instead of [[Category:GFDL]] we would
have [[category:License:GFDL]].
I know technically "Public domain" is not a license. but close enough.
So, the second problem, keywords. Let's reduce this to an easier
(although less complete :)) problem: categories. Being able to have
per-category feeds would be extremely cool. Imagine such a feed on QI
or FP. Totally awesome.
So in general we can assume that categories on a file act as
describing keywords. There are two exceptions. One is license
categories (see above). The other is maintenance categories, such as
deletion, cleanup, user.
So I propose we rename all these kinds of categories, to
"Maintenance:X" or "Meta:X" for deletion and cleanup, and I guess
"User:X" for user.
I dunno. maybe these don't interfere too much. Sometimes they are
useful. This change is not as important as the license one.
In general, I think it is good for us to look at Flickr and say: how
do they facilitate sharing their content? how can we do that too?
cheers,
Brianna
user:pfctdayelise
--
They've just been waiting in a mountain for the right moment:
http://modernthings.org/
Re: the discussion about an API and external tools,
We have a bit of a problem in that we are using both the toolserver
and the regular servers in ways they were not intended for. They are
both really intended for Wikimedia-internal use. If we use them for
external tools, Wikimedia does not directly benefit. If we were to
have any great success, it would likely backfire and result in the
thing being shut down or restricted.
So, do you think we should (sometime in the future, not tomorrow :))
consider approaching a chapter or outside org to donate hardware
specifically for this purpose?
Call it the Commons thumbcache server.
cheers
Brianna
--
They've just been waiting in a mountain for the right moment:
http://modernthings.org/
Hello
I'm part of the organization commitee for Wikipedia Day Berne 2007 which
will take place Sept 29th. To show that Wikimedia is not equal Wikipedia
we decided to print 12 images about Switzerland poster size and glue
them on aluminum plates.
The images will be shown on Open Expo in Zurich on Sept 19th too.
So all we need is good nominations of Swiss images. You know some?
Nominate here:
http://commons.wikimedia.org/wiki/Commons:Wikipediatag-2007-Galerie
Thanks!
Robin Schwab
OK Wikipediatag
Wikimedia CH - Verein zur Förderung Freien Wissens
Dear all,
You may have heard of Luc Viatour, aka [[User:LViatour]] : he is one of our
best contributors on Commons, has uploaded hundreds of very good quality
pictures and about 30 of his pictures have received the "Featured Pictures"
status.
Now someone has proposed his "copyright template" for deletion, while saying
"Unless his template is moved to userspace and substed in all cases, it and
all it tags (all images of Lviatour) should be deleted", which I think is
very rude and aggressive. The deletion request is on
http://commons.wikimedia.org/wiki/Commons:Deletion_requests/Images_of_Lviat….
Now I'm asking, what is this stupid rule about about personal copyright
template ? This one (ie
http://commons.wikimedia.org/wiki/Template:LviatourCredit ) doesn't do any
harm :
1) It includes a double license GFDL-CC-BY-SA, and that's all.
2) It tells people who is the author and how to re-use the image, which is
very good (see the related discussion about people not knowing how to reuse
images from Commons)
3) It says that "an email would be appreciated", which is not against the
rules as it is not mandatory.
Now if we start deleting templates like this, we can surely say goodbye to
our best contributors. We surely do not want people like Luc Viatour to get
out from Commons, do we ?
Regards,
Rémi
http://commons.wikimedia.org/wiki/User:Korrigan
There is a discussion that is just starting on the English Wiktionary
about the possibility of disabling local uploads.
I don't have figures, but there are not many images used on the project
and I doubt there are many uploaded anyway. Of the images that are used,
I'd be suprised if more than a handful at most were fair use and thus
unsuitable for commons.
Most of the media is audio files, and again I don't have figures but if
even 1% are not suitable for Commons I would be suprised.
The discussion is at
http://en.wiktionary.org/wiki/Wiktionary:Beer_parlour#Disable_file_uploadin…
Chris
--
Chris McKenna
cmckenna(a)sucs.org
www.sucs.org/~cmckenna
The essential things in life are seen not with the eyes,
but with the heart
Antoine de Saint Exupery
There's a reasonable amount of stuff about SVG + mobiles and SVG +
GIS. If anyone just happens to be hanging around Tokyo in the next two
or three weeks it might be worth popping in. ;)
cheers
Brianna
--
They've just been waiting in a mountain for the right moment:
http://modernthings.org/
WMI = Wikimedia Israel, a chapter
PicWik = "pictures for Wikimedia", internal name for their historical
picture collecting project
An English translation of the project spec is available at meta, who
are interested to know more about it:
http://meta.wikimedia.org/wiki/Free_image_collection_project
cheers,
Brianna
--
They've just been waiting in a mountain for the right moment:
http://modernthings.org/
In short, our category system is completely screwed up.
I've complained about this in the past, but it only seems to be getting worse.
If you follow the category hierarchy you'll find over 26,000 sub*cats*
of Category:GFDL, for example.
On the mean number of decedents of commons categories is 110
subcategories after full expansion.
There are 29 categories from which you can reach at least 90% of the
total categories used on commons.
Just a list of all the categories and their children is over 400mbytes of text.
Limiting the depth of traversal doesn't work because doing so would
result in terrible brokenness, such as randomly failing to return a
particular flower picture when someone searches for "flowers" just
because someone decided to split Category:White Flowers into "Grey
flowers" and "light white flowers" thus moving some of the images a
level too deep.
Many of the broken linkages aren't especially deep.
This is brokenness which goes far beyond the semantic drift issues
that I've argued make implicit category assignment fundamentally
flawed. (although some of it is through semantic drift,
cat:astronomical objects includes everything on earth through a
completely useless but piecewise sensible path)
What I need to know is: What do you need from me in order to fix this?
I can provide, via JS insertion of data from a toolserver tool, a list
on the category page of all the children of that category. However,
which many cats with over 1000 decedents... you might be waiting a
while for some pages to load.
Alternatively I could provide. via the same means. a list of the
children of a category at the top of the category (working around the
subcats display complaint in bugzilla).
I can provide reports such as what are the deepest linkages which
carry the most children, and which categories have the most
descendants.
What do we need to fix this? I've already given my solution (apply all
categories that make sense to images, and only use the hierarchy to
help with finding and suggesting cats).
Some background:
I recently put up a tool which enables very fast intersections of
commons categories. The same back end can be used for blindingly fast
geographic searches, and text searches.
http://tools.wikimedia.de/~gmaxwell/cgi-bin/cattersect.py
It's already a useful tool for finding images, but it's substantially
limited by the fact that categories are broken into tiny groups and
the tool can not dynamically walk the category hierarchy.
I've long argued that we need to avoid the category hierarchy issue by
applying all applicable categories directly to the image, and reserve
the hierarchy for pure category maintenance purposes.
I've realized that despite the merits of my position (argued
elsewhere), it simply isn't going to get traction in our community.
So in the interest of making progress I started working on finding a
solution to making the tool support following the category hierarchy.
I've got something which I think will work fairly well, ... it doesn't
break live update for image data, though it does require batch updates
of the category tree data. ... I would have had it up tonight were our
category data not so badly broken.