The attributes below match better Commons Book template [1] than commons Artwork template [2]. One difference is that Book template is a better fit for non- unique objects as it is lacking “Current location” and “Accession number” fields essential for Artwork.

Here are the mappings to current templates:

Zotero label	CSL fieldname	MapWarper	template:Book	template:Artwork
Scale	none	scale	-> description	-> description
Language	none		language
Short Title	none		-> title	-> title
Library Catalog	none
Rights	none		permission	permission
ISBN	ISBN		ISBN
URL	URL	Source / Bibliographic Ref URL	source	source
Abstract	abstract		-> description	-> description
Accessed	accessed
Archive	archive			current location (institution)
Loc. in Archive	archive_location			current location(location)
Call Number	call-number	Call Number		Accession number
Series Title	collection-title		Series Title
Edition	edition		Edition
Place	event-place and publisher-place	Place of Publication	Place of publication (City)
Type	genre			object type
Date	issued	Published Date	Date	date
Extra	note			notes
Publisher	publisher	Publisher	Publisher
Title	title	title	title	title
		description	description	description
		tags
		subject area	-> description	-> description
		Metadata Unique iD
		Author	author	artist
		Date Depicted	->date	->date
		Reprint Date	->date	->date
		Metadata Projection	-> description	-> description
		Metadata Location: lat, lon	template:Object location	template:Object location

I used “->field” symbol for cases where few external fields can be mapped to one template field.

Commons templates can be expanded a little bit in case of individual files with help of Template:Information_field [3]. But that makes hard to read wikicode. So I see 2 options here:

1) Expand current commons templates. Several times in last year I run into a problem of unique written documents which were right in the middle between {{Book}} and {{Artwork}}. I think {{book}} might benefit from fields that allow describing institution that hold it ( institution, location/department within the institution, accession number). We can propose adding those.

2) We can create a new {{Map}} template (either from scratch or by expanding other templates) that would accommodate this and possibly other fields which are now placed in description field of files (N S W E limits, projection/S stretch, etc.). Some of those fields might lend themselves into automatic KML production.

Jarek T.

User:jarekt

[1] http://commons.wikimedia.org/wiki/Template:Book

[2] http://commons.wikimedia.org/wiki/Template:Artwork

[3] http://commons.wikimedia.org/wiki/Template:Information_field

From: susanna.anas@gmail.com [mailto:susanna.anas@gmail.com] On Behalf Of Susanna Ånäs
Sent: Thursday, May 30, 2013 3:20 PM
To: Tim Alder
Cc: Map integration; Tuszynski, Jaroslaw W.; Valentine Charles; dan entous; David Haskiya
Subject: Re: [Maps-l] Wikimaps: About the template for maps

Let's stick to the mailing list!

If you want to keep up with the rest of the discussion, it would be beneficial to subscribe to the list. With this thread I think we can continue as is.

Let's continue. We need to get

- opinions/information about relevant bibliographic metadata schemes

- whatever the mapwarper stores with a rectified map

Here are the map attributes from MapWarper:

Title

Description

Tags

Subject area/Event place

Metadata unique ID

Call number = accession number?

Publisher

Place of publication

Date of publication = date?

Date depicted

Reprint date

Scale

Metadata projection

Metadata location: lat + lon

Language

Library Catalogue

ISBN

URL

Accessed

Series title

Edition

Cheers,

Susanna

2013/5/30 Tim Alder <tim.alder@s2002.tu-chemnitz.de>

Thanks Jarek to remember the old KML-overlay solution (A project of User:Dschwen and me from 2007). The KML-solution had very limited features to make complex transformation to map an historical map on the actual world, but we can use the principle to provide via a template a link to a tool that use data from an Wiki subpage.

With the KML-solution we could only store lat, lon, 2 values for scaling the map and rotation angle. Now I would store a list of matching points with x,y in pixel of the map and lat,lon. Would this be ok for Maps-wraper? (I'm not an expert in this area.)

Like Maarten Dammers I want to make a first rapid hack as a base for the final solution.

If we know the parameter definition I could hack a template let's say "overlay2" that opens the right page in Maps-wraper's map viewer[1]. For this it would be nice if Maps-wraper could work with Commons imagenames as identifier instead of numbers. Would these be possible?

The Maps-wraper should have on the other side an export page for the matching parameters so that a user can store it on commons at a subpage.

The advantage of the KML-solution was that we don't need any caching storage. Now the transformations cost a lot of cpu-time so we need a caching of the tiles at maps-wraper.

Greetings Tim Alder

P.S: I think we should organize the communication so that every mail is going directly to everone or we should use only the maps-l mailing list[2]. So it is confusing. I would prefer the mailing list but don't want to loose anyone how is interested. Sussana should decide.

[1] http://maps-warper.instance-proxy.wmflabs.org/maps/1
[2] https://lists.wikimedia.org/mailman/listinfo/maps-l

2013/5/30 Tuszynski, Jaroslaw W. <JAROSLAW.W.TUSZYNSKI@saic.com

<mailto:JAROSLAW.W.TUSZYNSKI@saic.com>>

Hi all,____

__ __

A standard, way of geolocating maps involves use of subpages with
KML code. See for example
http://commons.wikimedia.org/wiki/File:Dayton,_Indiana_1878.png and
http://commons.wikimedia.org/wiki/File:Dayton,_Indiana_1878.png/overlay.kml
. There was not a whole lot of people creating those KML’s and the
software often does not like the subpages of files, but the
infrastructure is there ready to use. If there was more interest in
using them we could discuss some improvements to the system. We
could also streamline kml production based on available data. Most
current files are created using North/South/East/West edges and
possible rotation. It might be more convenient to use coordinates of

4 corners, which is a format also supported by KML. ____

__ __

Another possibility would be to use Template:GeoPolygon, or both. ____

__ __

Are there any other fields specific to maps that are not
template:Artwork? We could always upload a few sample images by hand
(or pick existing ones) and ask community for help on formatting
metadata, which would be than used as a template (using non
Wikipedia meaning of the word) for the other uploads. That way we
can easily see what are the possible improvements to Commons

templates (using Wikipedia meaning of the word).____

__ __

We could also create a specialized template for maps, which could be
just extension of Artwork template. But it would be the best to
avoid that if not necessary. Rarely used templates tend to get

little attention and maintenance. ____

__ __

Jarek T.____

User:jarekt____

Susanna Ånäs
Wikimedia Suomi

GLAM – tiedotus – yhteistyö

Puhelin: +358 40 557 8039
Sähköposti: susanna.anas@wikimedia.fi

Wikimedia Suomi -blogi on aloitettu! Seuraa meitä Twitterissä @WMFinland tai Facebookissa. Liity jäseneksi!

Zotero label	Zotero fieldname	CSL fieldname
Scale	scale	none
Language	language	none
Short Title	shortTitle	none
Library Catalog	libraryCatalog	none
Rights	rights	none
ISBN	ISBN	ISBN
URL	url	URL
Abstract	abstractNote	abstract
Accessed	accessDate	accessed
Archive	archive	archive
Loc. in Archive	archiveLocation	archive_location
Call Number	callNumber	call-number
Series Title	seriesTitle	collection-title
Edition	edition	edition
Place	place	event-place and publisher-place
Type	mapType	genre
Date	date	issued
Extra	extra	note
Publisher	publisher	publisher
Title	title	title