Dear glamtools list, TL;DR version: In the light of the 2015 business plan, the scope of Europeana's grant application (and involvement in future development) of the GLAMwikiToolset needs to be scaled back to things that have a more direct/obvious relationship to Europeana's mission. I would like your suggestions for what those elements should be.
Full version: As the practitioners of the GLAMwikiToolset, the people who know the system, its history/purpose, its abilities and its flaws the best, I thought it important to relay to you directly a message that I delivered to the Wikimedia-l mailing list over the weekend.
*The background story...* On that mailing list (for those who are not subscribed to it) there has been a long thread instigated by Erik Moeller on the topic of how the WMF would like to encourage Chapters to take up responsibility for GLAM-related software/tooling. Obviously the GWT and Europeana's involvement came up in this context and I've been actively engaged in the discussion.
On Friday was the Europeana AGM in Madrid where the annual plan was publicly discussed. It just so happened that at the exact time the keynote presentation about the 2015 Business Plan was happening, the Wikimedia-l thread renewed, with specific discussion of Europeana's planned commitment to the GWT next year. Incredibly precise timing!
*The change of direction...* Of course, what no one knew was that within the context of this Europeana planning, I have been given specific instructions from senior management that a new round of intensive development on a content-agnostic, integrated mass-upload system for Wikimedia Commons is not within the scope of the mission of Europeana. Europeana is, after-all, an organisation focused on European digital cultural heritage but the GWT is a tool that can be used by anyone, from anywhere, for any kind of content that is acceptable to Wikimedia Commons. Further development of the infrastructure of the GWT work would increasingly be focused on areas that are further and further from the mission of Europeana. Europeana DOES wish to continue to develop the GWT in ways that directly support the mission of the organisation, but it has decided NOT to attempt to build the current tool into an all-singing-all-dancing fully integrated system for Commons. It's not about the cost specifically (though potential for 'scope creep' and therefore for budget overrun would have been very probable), but about being focused on the mission of the organisation.
This what I wrote publicly on Friday: https://lists.wikimedia.org/pipermail/wikimedia-l/2014-October/075203.html
From a personal perspective, as the guy who was pushing for the
funding/creation of the magical, easy, beautiful mass-upload system since... I forget how long ago now... I would love to see investment (by anyone), but in my professional perspective I understand the need for Europeana to clearly define the scope of its activities.
*Timing difficulties...* I would have liked to have this discussion more slowly and deliberatively but in the context of the AGM and the Wikimedia-l conversation happening, my boss and I agreed that it was important to be clear on the public record as quickly as possible so as not to have any false expectations (or, as few as possible!). I would have preferred to have shared this here first obviously but things don't always work out neatly like that. Apologies.
Two other aspects of things that, as a result of this change, didn't work out neatly timing-wise is that we are in the middle of both: a) the EuropeanaTask Force to write a recommended strategy for Europeana's relationship to Wikimedia in accordance with the 2015-2020 strategic plan. b) writing the grant application to the WikimediaFoundation for funding future development of the GWT itself.
The first point (the Task Force) is a strategic discussion and so, technically, is a higher-level of planning than the specific software development plans for the GWT. However, in reality, what Europeana invests in the GWT does obviously have implications for the longer-term strategy. Ideally report from the Task Force would be submitted *first *and the decision on the scope investment in the GWT would come as a result of it, but the timing of the annual planning precluded that.
The second point (the grant application) means a bit of re-writing and re-scoping...
*The request...* Therefore, I would like your advise and suggestions as to what you, the practitioners of the GWT, believe to be the elements which *should *be included in the newly-rewritten WMF grant application, given this specific clarification from Europeana. Given that: - we know that there are many things which we could do to improve the GWT - we know that Europeana will only develop things that have specific relevance to European digital cultural heritage - we know that the WMF will not approve an application for funding technical development if its value is limited to only a small group
We need to identify the aspects of the GWT that will have the most impact if improved but are also: *specific *to be listed in the grant application, *achievable *within the time/money/people resources available*, relevant *to the needs of Europeana and the WMF (think SMART criteria https://en.wikipedia.org/wiki/SMART_criteria). I've got a few points obviously, but I'd very much appreciate if you could add to this list:
- Usability improvements for the current workflow to ensure that the process as it currently stands is clearly explained within the system (including some user testing) - Documentation completion/improvements (including screencasts and linking the steps of the process to the relevant parts of the documentation) - Building a report on the needs of GLAMs to be able to export their data back out of commons (the equivalent of this Europeana-sponsored report into https://commons.wikimedia.org/wiki/File:Report_on_requirements_for_usage_and_reuse_statistics_for_GLAM_content.pdfrequirements for usage and reuse statistics for GLAM content https://commons.wikimedia.org/wiki/File:Report_on_requirements_for_usage_and_reuse_statistics_for_GLAM_content.pdf ) - Building the API that will easily push content already in Europeana (i.e. Is using the EDM - Europeana data model) to easily export to a GWT compliant file. - Supporting the development of the Structured Data project (somehow!)
Suggestions welcome! -Liam
wittylama.com Peace, love & metadata
Hey Liam, i'm glad that you're openly stating all the problems. It's always better to be transparent in these kinds of situations.
Anyways, considering the next steps:
On Tue, Nov 4, 2014 at 11:16 AM, Liam Wyatt liamwyatt@gmail.com wrote:
- Usability improvements for the current workflow to ensure that the process
as it currently stands is clearly explained within the system (including some user testing)
My #1 request would be better options to 'mash' and 'shape' the incoming XML. Maybe you could argue that this is something that should be done *before* stuff even gets into the GWT, but IMO we are very lucky to even get GLAM professionals that know what XML is and can get it from their API. It's a bit optimistic to think that they can also write their own XML transformers like i did with GWT Cook [1] :)
- Building a report on the needs of GLAMs to be able to export their data
back out of commons (the equivalent of this Europeana-sponsored report into requirements for usage and reuse statistics for GLAM content)
Obviously this needs to fit in with the work that the WMF metrics/analytics team is currently doing because the current options (BaGLAMa / Glamarous) are just stopgaps that Magnus lovingly coded but aren't really fit for the long term.
- Building the API that will easily push content already in Europeana (i.e.
Is using the EDM - Europeana data model) to easily export to a GWT compliant file.
Sure. I guess this might be one way to convince Europeana to keep doing some development work.
- Supporting the development of the Structured Data project (somehow!)
And that would be the #2 request. Hopefully we'll have a better view of what will happen with that after the Amsterdam hackathon next week.
-- Hay
Hi Liam,
Specifically in relation to these two points:
- Building a report on the needs of GLAMs to be able to export their data
back out of commons (the equivalent of this Europeana-sponsored report into requirements for usage and reuse statistics for GLAM content https://commons.wikimedia.org/wiki/File:Report_on_requirements_for_usage_and...
- Supporting the development of the Structured Data project (somehow!)
I think something that would be useful (and urgent) would be looking quite hard at what's going to be needed to extract data from the new Structured Data system into EDM.
In particular, it would be good to know that metadata will be able to be migrated
Museum -> Commons Structured Data -> EDM
with no more loss than would be entailed by going
Museum -> EDM
Looking at first drafts of the Structured Data proposals, I am very concerned that the proposed structure may not allow deep enough grouping of related properties -- eg grouping together artist/contribution/date/licence information on each stage of contribution for an image that may be the result of multiple successive stages of contribution.
(eg original work by painter -> engraving by sketcher and artist -> scan by museum team : each of these stages have distinct information which ought to be properly grouped.)
The problem is that the current item/property/qualifier hierarchy used on Wikidata may be one step too shallow to permit this kind of grouping for image metadata for a particular file.
There may be more gotchas that I'm not aware of, because I don't yet know enough about EDM.
So more running of a rule over the Structured Data plans to make sure that they are compatible with EDM would be timely, I think, to make sure that the pathway will be there to export to EDM without loss.
Probably it would also be useful to look over similar evolving Structured Data proposals for category-type data, to ensure they can export to standards like IIIF.
-- James.
Hello everyone!
I'm quite a newcomer here but since I'm working with the GWToolset uploads currently, I thought I could say something here.
I think that "mash and shape" are the keywords here. I have understood that the reason for uploading content to commons is to have it linked. Although, this can be partly done automatically, there a lot of situations that must be handled by hand.
I see two options:
1. Source (like Europeana) -> "mash and shape" -> outputs XML for GWToolset -> upload to Commons (wikitalisation)
2. Source (like Europeana) -> outputs XML for GWToolset -> "mash and shape" -> upload to Commons
(wikitalisation)
Personally I like the option 1 because it is more flexible. I can develop "mash and shape" tools as I please. This is what I'm doing right now but with Flickr. I'm developing a simple tool for the Flickr materials of Finnish GLAMs that allows editing metadata and then output the XML for the GWToolset.
In the option 2, I loose that control. Of course, these options does not necessarily exclude each other.
My point is that "mash and shape" is probably different for Europeana compared to some other data source (like Flickr or some museum database for example). Europeana could set best practices for their "mash and shape" tool. And if someone is not happy with it, then they can freely develop external tool.
I'm not sure if this was helpful at all. I really like the way GWToolset works and I'm very interest about it's future.
Best regards, Ari Häyrinen WMFI
ps. More about our Flickr and Commons thing in today's GLAMout :) https://en.wikipedia.org/wiki/Wikipedia:GLAM/GLAMout/2014/November
Sent from my Debian. http://www.opendimension.org/
2014-11-04 13:25 GMT+02:00 James Heald j.heald@ucl.ac.uk:
Hi Liam,
Specifically in relation to these two points:
- Building a report on the needs of GLAMs to be able to export their data
back out of commons (the equivalent of this Europeana-sponsored report into requirements for usage and reuse statistics for GLAM content https://commons.wikimedia.org/wiki/File:Report_on_ requirements_for_usage_and_reuse_statistics_for_GLAM_content.pdf>
- Supporting the development of the Structured Data project (somehow!)
I think something that would be useful (and urgent) would be looking quite hard at what's going to be needed to extract data from the new Structured Data system into EDM.
In particular, it would be good to know that metadata will be able to be migrated
Museum -> Commons Structured Data -> EDM
with no more loss than would be entailed by going
Museum -> EDM
Looking at first drafts of the Structured Data proposals, I am very concerned that the proposed structure may not allow deep enough grouping of related properties -- eg grouping together artist/contribution/date/licence information on each stage of contribution for an image that may be the result of multiple successive stages of contribution.
(eg original work by painter -> engraving by sketcher and artist -> scan by museum team : each of these stages have distinct information which ought to be properly grouped.)
The problem is that the current item/property/qualifier hierarchy used on Wikidata may be one step too shallow to permit this kind of grouping for image metadata for a particular file.
There may be more gotchas that I'm not aware of, because I don't yet know enough about EDM.
So more running of a rule over the Structured Data plans to make sure that they are compatible with EDM would be timely, I think, to make sure that the pathway will be there to export to EDM without loss.
Probably it would also be useful to look over similar evolving Structured Data proposals for category-type data, to ensure they can export to standards like IIIF.
-- James.
Glamtools mailing list Glamtools@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/glamtools
Ideally what we would like as a next stage is a user interface improvement, the underpinning technology works and can be refined to match.
This solves the usability issues. For example rather than talking xml, it makes more sense to point a tool at your online archive (or hard disk collection) and for it to sniff out media files and suggest an intial mapping that the user than refines by moving mappings about in a visual interface.
This can be particularly hard to get right if there are complex multiple maps. For example "date" could be artefact date, find date, scan date, photograph date, restoration date, derived work date, publication date... as well as the date itself being ranges, periods, estimates, maximum date etc.
I'm in the Netherlands for the next Europeana meeting (hopefully someone will cover my expenses even if I have to be co-opted on a task force) and this might be the best time to discuss how we refresh the steering group, and call for new members, which can then push the next evolution and coordinate with the WMF, chapters and Europeana - none of which are right to lead on this by themselves.
Fae
Dear all, I would like to add a couple of points and questions as a small user of the tool with limited competences, which I hope are pertinent to this discussion. I used GWT once and although with some difficulties I am very happy with the feedback and support I received and with the result at the end. The learning curve and the untold requirement (=know somebody) are what needs to be smoothed down urgently I believe. Usability: I agree with Fæ that some work on the interface would be very helpful and if this can also allow a bit more freedom in terms of templates, licenses (I had to enter the template for that, but perhaps there are ways in which a more generic statement can be transformed in the proper template or this can be picked from a list and eventually enriched), free descriptive text, etc. even better. I would add some workflow steps as those of the upload wizard to help out new users. When I did my upload my xml file after the testing phase in beta ended up being full of wiki text which I am not sure is what we want to do and most people can do. Documentation: Some parts of the process need also to be clarified in the description of the tool, so that people know that empty elements are a problem for the tool before they figure out, and perhaps get to know about the log and so on. (these I think are all known issues, if not I can expand my list) GLAM specific: Another important aspect would be to tailor this to GLAMs in terms of facilitating anything which concern templates: could there be a ready list of mappings from major documentation standards in use (LIDO, CIDOC CRM, etc.)? can files different from a flat xml be handled? most people in the GLAM community, in my opinion, will just be put of by reading "xml". is this what the mash and shape would enable people to do? take a file from their computer whichever it is and make the metadata into an xml file for the GWT without them noticing anything? than I put my +1 on that most certainly. Also: can more template be prepared and put in the tool for the mapping? perhaps one for each typology of object in europeana? can they be customizable from the tool itself? what about GLAMs which do not have their collections digitized or online? I understand that Commons is not their online repository, but there are a series of smaller institutions which could do amazing things if empowered by the tool to get their contents out there. this possibility for smaller and medium GLAMs would be in my opinion what enlarges the scope of the technical development enough to make it worth it. and it is a real need, because bigger institution will anyway have somebody to write a bot for them if they want to upload files to Commons, and it is going to be easier perhaps then using the GWT; small and medium GLAMs won't have any one. In this respect something about outreach to these institutions should be done, and this might happen via Europeana and the Chapters together. API/structured Data: isn't it true that the API will be there as soon as wikibase is used by Commons? is there any use in building one then? I think support to this side of things would be more important in the direction suggested by James Heald earlier on, so, if I well understood, towards making sure that the depth of grouping and organization is enough and not just a minimum (wikidata needs to keep a minimum because of what it is but I also think that that is not the logic in Commons) and that GLAM find their appropriate space there and do not feel constrained by this or that technical or design limit. If then the API communication is in place bidirectionally, and can possibly keep up with updates which might come from Commons or from Europeana Content providers, that would be even better. Then as a GWT user I would like to see what happens to the contents I uploaded in both Commons and Europeana, perhaps be informed about conflicting changes to be able to moderate where possible, and off course get back the data from one of the two. Europeana: It strikes me that Europeana thinks about this tool as somehow out of scope I have to say. The strategic plan says "we transform the world with culture", not "we transform europe with culture". I do not see the problem if something initially developed for institutions in the Europeana network and on their specific needs as test cases is then useful for GLAMs outside Europe. On the contrary I think it would fully fulfill our mission under many respects, let alone the key words of the strategy: Mutual, Usable, Reliable... These are my two cents, I hope they are of some use for the application. Sincerely yours Pietro
Il giorno 04/nov/2014, alle ore 11.16, Liam Wyatt ha scritto:
Dear glamtools list, TL;DR version: In the light of the 2015 business plan, the scope of Europeana's grant application (and involvement in future development) of the GLAMwikiToolset needs to be scaled back to things that have a more direct/obvious relationship to Europeana's mission. I would like your suggestions for what those elements should be.
Full version: As the practitioners of the GLAMwikiToolset, the people who know the system, its history/purpose, its abilities and its flaws the best, I thought it important to relay to you directly a message that I delivered to the Wikimedia-l mailing list over the weekend.
The background story... On that mailing list (for those who are not subscribed to it) there has been a long thread instigated by Erik Moeller on the topic of how the WMF would like to encourage Chapters to take up responsibility for GLAM-related software/tooling. Obviously the GWT and Europeana's involvement came up in this context and I've been actively engaged in the discussion.
On Friday was the Europeana AGM in Madrid where the annual plan was publicly discussed. It just so happened that at the exact time the keynote presentation about the 2015 Business Plan was happening, the Wikimedia-l thread renewed, with specific discussion of Europeana's planned commitment to the GWT next year. Incredibly precise timing!
The change of direction... Of course, what no one knew was that within the context of this Europeana planning, I have been given specific instructions from senior management that a new round of intensive development on a content-agnostic, integrated mass-upload system for Wikimedia Commons is not within the scope of the mission of Europeana. Europeana is, after-all, an organisation focused on European digital cultural heritage but the GWT is a tool that can be used by anyone, from anywhere, for any kind of content that is acceptable to Wikimedia Commons. Further development of the infrastructure of the GWT work would increasingly be focused on areas that are further and further from the mission of Europeana. Europeana DOES wish to continue to develop the GWT in ways that directly support the mission of the organisation, but it has decided NOT to attempt to build the current tool into an all-singing-all-dancing fully integrated system for Commons. It's not about the cost specifically (though potential for 'scope creep' and therefore for budget overrun would have been very probable), but about being focused on the mission of the organisation.
This what I wrote publicly on Friday: https://lists.wikimedia.org/pipermail/wikimedia-l/2014-October/075203.html
From a personal perspective, as the guy who was pushing for the funding/creation of the magical, easy, beautiful mass-upload system since... I forget how long ago now... I would love to see investment (by anyone), but in my professional perspective I understand the need for Europeana to clearly define the scope of its activities.
Timing difficulties... I would have liked to have this discussion more slowly and deliberatively but in the context of the AGM and the Wikimedia-l conversation happening, my boss and I agreed that it was important to be clear on the public record as quickly as possible so as not to have any false expectations (or, as few as possible!). I would have preferred to have shared this here first obviously but things don't always work out neatly like that. Apologies.
Two other aspects of things that, as a result of this change, didn't work out neatly timing-wise is that we are in the middle of both: a) the EuropeanaTask Force to write a recommended strategy for Europeana's relationship to Wikimedia in accordance with the 2015-2020 strategic plan. b) writing the grant application to the WikimediaFoundation for funding future development of the GWT itself.
The first point (the Task Force) is a strategic discussion and so, technically, is a higher-level of planning than the specific software development plans for the GWT. However, in reality, what Europeana invests in the GWT does obviously have implications for the longer-term strategy. Ideally report from the Task Force would be submitted first and the decision on the scope investment in the GWT would come as a result of it, but the timing of the annual planning precluded that.
The second point (the grant application) means a bit of re-writing and re-scoping...
The request... Therefore, I would like your advise and suggestions as to what you, the practitioners of the GWT, believe to be the elements which should be included in the newly-rewritten WMF grant application, given this specific clarification from Europeana. Given that:
- we know that there are many things which we could do to improve the GWT
- we know that Europeana will only develop things that have specific relevance to European digital cultural heritage
- we know that the WMF will not approve an application for funding technical development if its value is limited to only a small group
We need to identify the aspects of the GWT that will have the most impact if improved but are also: specific to be listed in the grant application, achievable within the time/money/people resources available, relevant to the needs of Europeana and the WMF (think SMART criteria). I've got a few points obviously, but I'd very much appreciate if you could add to this list:
- Usability improvements for the current workflow to ensure that the process as it currently stands is clearly explained within the system (including some user testing)
- Documentation completion/improvements (including screencasts and linking the steps of the process to the relevant parts of the documentation)
- Building a report on the needs of GLAMs to be able to export their data back out of commons (the equivalent of this Europeana-sponsored report into requirements for usage and reuse statistics for GLAM content)
- Building the API that will easily push content already in Europeana (i.e. Is using the EDM - Europeana data model) to easily export to a GWT compliant file.
- Supporting the development of the Structured Data project (somehow!)
Suggestions welcome! -Liam
wittylama.com Peace, love & metadata
-- wittylama.com Peace, love & metadata _______________________________________________ Glamtools mailing list Glamtools@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/glamtools
Liam Wyatt, 04/11/2014 11:16:
- we know that Europeana will only develop things that have specific
relevance to European digital cultural heritage
Does this include the needs identified by the respective custodians for the management/upload of material 1) of priority for Europeana, 2) from Europeana "members", 3) from any institution which ends up on Europeana (e.g. currently via The European Library), 4) not yet on Europeana but potentially so, 5) of any sort in Europe's institutions?
Concretely, I'm WIR at the European Library of Information and Culture (BEIC, http://www.beic.it ); should I see GWT as something Europeana is interested in supporting for us too or not?
Nemo
On 4 November 2014 17:53, Federico Leva (Nemo) nemowiki@gmail.com wrote:
Liam Wyatt, 04/11/2014 11:16:
- we know that Europeana will only develop things that have specific
relevance to European digital cultural heritage
Does this include the needs identified by the respective custodians for the management/upload of material
- of priority for Europeana,
- from Europeana "members",
- from any institution which ends up on Europeana (e.g. currently via The
European Library), 4) not yet on Europeana but potentially so, 5) of any sort in Europe's institutions?
Concretely, I'm WIR at the European Library of Information and Culture (BEIC, http://www.beic.it ); should I see GWT as something Europeana is interested in supporting for us too or not?
Nemo
You've actually hit upon a question that has been causing us some difficulty within the Europeana statistics/reporting meetings to describe the outcomes of Europeana on Wikimedia... We don't yet have a clear definition of what is 'in' scope, but it is at least a little easier to define what is 'out'.
It is something that we have had specific discussions about with regards to calculating the number of items on Commons that 'are related to' Europeana - using the Baglama too: We realised that we were unintentionally counting ALL files uploaded with the GLAMwikiToolset as related to Europeana (because there was a hidden sub-sub-sub category...) even when some of the uploaded files had nothing to do with Europe or cultural heritage. Moreover, Europeana does not want to appear to be 'taking credit' for someone else's uploads - that wouldn't be fair. But, in some hypothetical cases it might be a European GLAM that uploads by themselves without talking to any wikimedian or Europeana - should that count? One of the big shifts in Europeana's strategy over the last year or so is to move away from thinking that it all needs to be about Europeana's OWN website - and to be thinking about helping facilitate the GLAMs to re-use cultural heritage in many ways, even if that doesn't go via the Europeana portal. A much more sensible (and less egotistical) approach, but MUCH harder to measure success! :-)
So - it's a good question that Europeana doesn't have a good answer for. Your specific case, I would argue, DOES fall within the remit of something that Europeana would want to support of course. But clearly, as with any organisation of limited resources, if there are two things that are seeking attention simultaniously, the attention of the staff would naturally need to be given to those GLAMs that ARE formally Europeana partners.
Hope that helps, -Liam