Hi!
I am forwarding a discussion that I started with the people from Europeana on the metadata templates for maps. I would like to get your opinions about what should we cater for in the maps metadata template.
I am repeating Dan's points:
1. which metadata attributes would need to be stored?
2. is there a mediawiki template on commons that currently handles those metadata attributes? a. http://commons.wikimedia.org/wiki/Commons:Geocoding
b. http://commons.wikimedia.org/wiki/Template:Location
c. if not, how do we introduce a new template?
3. do we bring this additional functionality into current scope or later? a. what type of ui would be needed to add in the functionality?
Tim might have good arguments based on how he has handled metadata in a partnership with a maps GLAM in the MapWarper? Why should some information be omitted? Should the community decide or should we take standards into account? Which ones?
Cheers, Susanna
2013/5/30 Tuszynski, Jaroslaw W. 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****
*From:* Maarten Dammers [mailto:maarten@mdammers.nl] *Sent:* Wednesday, May 29, 2013 3:20 PM *To:* Susanna Ånäs *Cc:* David Haskiya; dan entous; Valentine Charles; Tuszynski, Jaroslaw W.
*Subject:* Re: About the template for maps****
Hi David and Susanna,
Like what I said on the hackathon: I generally like to get improve existing template instead of forking them. The whole location metadata is something you need to keep separate anyway, it would be a mess to try to fit that in the same template. I think in the long run this data needs to end up at Wikidata.
Maarten
Ps. Put Jarek on the cc.
Op 29-5-2013 20:08, Susanna Ånäs schreef:****
Hi all, ****
I am willing to gather more information from especially our map curator, plus perhaps our contact in the Land Survey regarding the simplest form of adequate metadata for maps. With Tim Alder we discussed that we do need at least the bounding box for the map, if it's available, though only after the map has a location. Realizing also that none of the existing templates for location only are perfect for our purpose.****
Please include relevant people in the discussion!****
Cheers,****
Susanna****
2013/5/29 David Haskiya David.Haskiya@kb.nl****
Hi Susanna, We gave up on trying to change/extend the default Artwork template (or any other template) as the community indicated that would not be a welcome or easy thing to do. So we use the default Book, Photo, Artwork and Species templates. Our contact was http://commons.wikimedia.org/wiki/User:Jarektwho is knowledgeable, friendly and constructive. I think we the more insider position you and Maarten have it should be possible to get support for a new template - I don't understand Wikimedia Common dynamics very well though. De-facto it looks like Artwork is the template used for historical maps.
If you and Maarten as part of your project create a specific Map template or a specific Artwork-Map template then adding it to our tool as a target template should be simple (unless it deviates strongly from the existing templates).
Cheers, David
Product Developer www.europeana.eu
Phone: +31 (0)70 3140 696 Mobile: +31 (0)64 217 2542 Email: david.haskiya@kb.nl Skype: davidhaskiya****
-----Original Message----- From: dan entous [mailto:d_entous@yahoo.com] Sent: woensdag 29 mei 2013 13:29 To: Susanna Ånäs Cc: David Haskiya; Valentine Charles Subject: Re: About the template for maps
hi susanna,
i'm including david haskiya and valentine charles in this response so
they
can also see your request and answer your questions as well.
artwork template
valentine had direct contact with someone involved with the artwork template. i don't know if she kept notes or email threads regarding the discussion. hopefully she or david can give you feedback in that regard.
adding map metadata
i'm sure we could sort something out in the tool that would allow you to add map metadata. at first glance, the following points would have to be decided :
which metadata attributes would need to be stored?
is there a mediawiki template on commons that currently handles those
metadata attributes? a. http://commons.wikimedia.org/wiki/Commons:Geocoding b. http://commons.wikimedia.org/wiki/Template:Location c. if not, how do we introduce a new template? - maarten dammers might know this process best
- do we bring this additional functionality into current scope or later? a. what type of ui would be needed to add in the functionality?
with kind regards, dan
sent from my mind to yours
(function signature() { return [ 'dan entous', 't. +31 (20) 684.5005', 'm. +31 (64) 024.6187' ].join('\n'); }());
On May 28, 2013, at 1:24 PM, Susanna Ånäs wrote:
Hi Dan,
In regard to the templete topic we discussed, I could ask some
additional questions.
It was Maarten Dammers' opinion that the Artwork template
(http://commons.wikimedia.org/wiki/Template:Artwork) is extensive enough to be able to handle maps. The template does not include a possibility of including information about a geographical bounding box. The idea Maarten proposed was to use another template for geodata in addition to the Artwork template. Now the tool does not support this.
I also learned that you had discussed about extending the Artwork
template in order to accommodate better to existing standards. Do you think you could find a way for me to follow that discussion?
My specific goal is nevertheless to have a possibility in the GLAM-Wiki
tool to have a template (structure) that meets the needs of map GLAMs, that it is enough standards compliant for that, and that it includes all necessary fields. When I discussed the metadata with the Antti Rainio
from
the Land Survey in Finland, he stated that the need of the INSPIRE are
too
complicated and a more flexible structure would be better, based on
Dublin
Core for example.
Hope to continue discussion.
Cheers, Susanna
I have now been able to register in the tool :)
2013/4/25 dan entous d_entous@yahoo.com hi susanna,
i just added you to the wiki. you should get an e-mail with a temporary
password. thereafter you should be able to test out the tool. just as a reminder, the tool may change very now and then as we're still in development, but you should be able to test it out in any case.
with kind regards, dan
sent from my mind to yours
(function signature() { return [ 'dan entous', 't. +31 (20) 684.5005', 'm. +31 (64) 024.6187' ].join('\n'); }());
On Apr 25, 2013, at 9:59 AM, Susanna Ånäs wrote:
Hi,
I would like to request for access to test the tools.
Susanna Ånäs User: Susannaanas
-- 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!
Glamtools mailing list Glamtools@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/glamtools
-- 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!****
-- ****
*Susanna Ånäs* Wikimedia Suomi http://fi.wikimedia.org/wiki/Etusivu ****
GLAM http://fi.wikipedia.org/wiki/Wikipedia:GLAM – tiedotus – yhteistyö
Puhelin: +358 40 557 8039 Sähköposti: susanna.anas@wikimedia.fi****
Wikimedia Suomi http://blog.wikimedia.fi/ -blogi on aloitettu! Seuraa meitä Twitterissä @ https://twitter.com/WMFinlandWMFinlandhttps://twitter.com/WMFinlandtai Facebookissa https://www.facebook.com/WikimediaSuomi. Liity jäseneksi!http://fi.wikimedia.org/wiki/Liity_j%C3%A4seneksi
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____
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 Metadata Unique iD Source / Bibliographic Ref URL Call Number Publisher Place of Publication Author(s) Date Depicted Published Date Reprint Date Scale Metadata Projection Metadata Location: lat, lon
Here's what Zotero offers:
*Zotero label**Zotero fieldname**CSL fieldname*Scalescale*none*Language language*none*Short TitleshortTitle*none*Library CataloglibraryCatalog*none* Rightsrights*none*ISBNISBNISBNURLurlURLAbstractabstractNoteabstractAccessed accessDateaccessedArchivearchivearchiveLoc. in ArchivearchiveLocation archive_locationCall NumbercallNumbercall-numberSeries TitleseriesTitle collection-titleEditioneditioneditionPlaceplaceevent-place *and* publisher-placeTypemapTypegenreDatedateissuedExtraextranotePublisher publisherpublisherTitletitletitle Here's my summary of fields from these 2 sources that are not in the Artwork template: Map type 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/1http://maps-warper.instance-proxy.wmflabs.org/maps/1 [2] https://lists.wikimedia.org/**mailman/listinfo/maps-lhttps://lists.wikimedia.org/mailman/listinfo/maps-l
2013/5/30 Tuszynski, Jaroslaw W. <JAROSLAW.W.TUSZYNSKI@saic.com <mailto:JAROSLAW.W.TUSZYNSKI@**saic.com 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<http://commons.wikimedia.org/wiki/File:Dayton,_Indiana_1878.png>and http://commons.wikimedia.org/**wiki/File:Dayton,_Indiana_**
1878.png/overlay.kmlhttp://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____
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
Metadata Unique iD
Source / Bibliographic Ref URL
Call Number
Publisher
Place of Publication
Author(s)
Date Depicted
Published Date
Reprint Date
Scale
Metadata Projection
Metadata Location: lat, lon
Here's what Zotero offers:
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
Here's my summary of fields from these 2 sources that are not in the Artwork template:
Map type
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____
I like your work!
Based on this discussion, I vote for creating a new {{Map}} template.
Still, I am missing some librarian voice in the discussion.
Cheers, Susanna
2013/5/31 Tuszynski, Jaroslaw W. JAROSLAW.W.TUSZYNSKI@saic.com
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****
Metadata Unique iD****
Source / Bibliographic Ref URL****
Call Number****
Publisher****
Place of Publication****
Author(s)****
Date Depicted****
Published Date****
Reprint Date****
Scale****
Metadata Projection****
Metadata Location: lat, lon****
Here's what Zotero offers:****
*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****
Here's my summary of fields from these 2 sources that are not in the Artwork template:****
Map type****
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____
Hi all,
I wrote down the summary from our discussion on http://commons.wikimedia.org/wiki/Commons:Wikimaps/Template.
The basic proposal is to create a new template {{Template:Map}} for maps, that adds publication and location data to the Artwork template. - Jarek was opting to use only one template. - Tim A. noted that there are so many maps that are using the Artwork template, that having Artwork + an additional Map template will be beneficial. The data would be stored in Wikidata soon anyway.
The proposal is with 2 templates. Can that be handled in the GLAMwiki tool?
Please comment the properties on the page or here.
Happy weekend, Susanna
2013/6/3 Susanna Ånäs susanna.anas@wikimedia.fi
I like your work!
Based on this discussion, I vote for creating a new {{Map}} template.
Still, I am missing some librarian voice in the discussion.
Cheers, Susanna
2013/5/31 Tuszynski, Jaroslaw W. JAROSLAW.W.TUSZYNSKI@saic.com
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****
Metadata Unique iD****
Source / Bibliographic Ref URL****
Call Number****
Publisher****
Place of Publication****
Author(s)****
Date Depicted****
Published Date****
Reprint Date****
Scale****
Metadata Projection****
Metadata Location: lat, lon****
Here's what Zotero offers:****
*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****
Here's my summary of fields from these 2 sources that are not in the Artwork template:****
Map type****
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____