Hi David,

I am afraid that having 2 separate templates one after the other is what people have been suggesting.
I am currently working on a real-life example from the National Archives. I will document it as soon as I have it ready.

Thanks for the answer!

Best,
Susanna



2013/6/7 David Haskiya <David.Haskiya@kb.nl>

Hi Susanna,

You can have templates within a template in the GLAMwiki tool, yes. A real or mocked-up example would allow for a more exact estimation of what implementation in the tool would demand.

 

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


From: susanna.anas@gmail.com [mailto:susanna.anas@gmail.com] On Behalf Of Susanna Ånäs
Sent: vrijdag 7 juni 2013 13:59
To: Tuszynski, Jaroslaw W.
Cc: Map integration; Valentine Charles; dan entous; David Haskiya; Lesley Kadish
Subject: Re: [Maps-l] Wikimaps: About the template for maps

 

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____