Uploading and describing content in a digital asset management system requires an efficient process, easily integrated into people's daily work habits. In December we kicked off a project to design and implement a simplified workflow for managing design products, taking advantage of our new embedded metadata (XMP) standard. Sometimes talking about workflows can feel like dancing about architecture, so I decided to try a more hands-on workshop as part of the project.
Showing posts with label digital asset management. Show all posts
Showing posts with label digital asset management. Show all posts
Friday, 3 January 2014
Friday, 12 April 2013
Next steps for City of Toronto digital asset management
 |
| Our next phase includes management of communications products such as this City Hall green roof ad. |
Since launching the City of Toronto's digital asset management program, we have focused on the upload, description and management of digital photographs. Our next steps include expanding to new content types and users, as well as improving reporting, rights management and governance. We are building on our foundational work completed in 2012 to make it easier to upload, share and reuse files.
1. Managing Communications Products
Phase 2 includes the upload and management of communications materials, both final PDFs and layout files, linked to high-resolution original images or graphics. Unlike a batch of photographs shot to document a single event, communications materials can have more complex relationships and require more detailed item-level descriptions. This will be a significant change in how staff work. The transition should be made easier by simplified file descriptions and embedded metadata, allowing us to reuse existing descriptive information.
2. Partnership with New Divisions
Currently the Digital Asset Library (DAL) is used by staff in City Clerk's Office and City Planning only. We are in the planning stages to pilot with new divisions, including:
- Parks, Forestry & Recreation
- Public Health
- Shelter, Support & Housing Administration
- Economic Development & Culture
3. Reporting Project
This project will deliver improved reporting capabilities, enabling program management and divisional partners to better measure performance, usage trends and identify potential improvements.
4. Access, Rights and Reuse Project
Current and future partners are increasingly seeking advice and guidance on image rights management. To meet this need, the City of Toronto Archives intends to develop DAL as a tool to manage copyright and related rights information of the City's digital assets. In consultation with our divisional partners, it is our intention to develop a simplified model to enable reuse.
5. Establishment of Steering Committee
Our approved program recommendations included a steering committee model to support DAL in meeting goals, prioritizing projects and allocating resources to deliver them. We will be working with representatives from our divisional partners to establish this committee.
We have set out ambitious plans for our next phase, based on staff feedback and program goals. I'm looking forward to working with our partners to improve collaboration, sharing and reuse of digital photographs and communications materials around the City of Toronto.
Thursday, 31 January 2013
Digital Asset Library year in review - 2012
 |
| Christmas decorations at City Hall and Nathan Phillips Square skating rink, by Jose San Juan |
Thursday, 1 November 2012
metadata - use it or lose it
Over this fall I have recruited representatives from our participating units who are working with me to simplify our digital asset management system. Not surprisingly, we have no shortage of ideas for new functionality or updates! However, our challenge has been to develop recommendations that we could implement ourselves, without requiring expensive customizations. We focused on simplifying the descriptive metadata that must be applied to assets when importing.
As discussed in my previous post, there are principles we can apply when considering which metadata fields to hide or remove. Streamlining also means reworking the remaining fields so they are easier to use for all groups. Here's a few more general principles derived from experience and information standards:
As discussed in my previous post, there are principles we can apply when considering which metadata fields to hide or remove. Streamlining also means reworking the remaining fields so they are easier to use for all groups. Here's a few more general principles derived from experience and information standards:
- Use it or lose it
- Mutual exclusivity
- Use the language of your users
- Use terms important to organizational context
Tuesday, 16 October 2012
Principles for simplifying DAM file descriptions
Our digital asset management project was launched with a goal of making it easier to find, share and reuse images and graphic assets across the City of Toronto. Participating staff can now access images from the official photographers and the City Planning photographer from a central location. After 1 year of use, we are in a good position to look for opportunities to improve for existing and future users.
When the system went live in 2011, it incorporated the requirements of four different business units. During the development process, metadata fields were added anticipating future functionality or to create an exhaustive list of descriptive information. The list grew as each group identified what seemed to be unique details or processes. The result was a fairly large set of metadata (50 fields!). Before launch, we reviewed the overal set and developed a custom profile for each group. Here's an example, from our Photo Video unit:
You can imagine that this list might be somewhat daunting for new users! Keep in mind that some fields are left blank for certain files, and some are automatically captured.
"Make it simpler"
If all our staff feedback could be reduced into a single idea, this would be it. Even a seasoned cataloger might be challenged by our set of metadata at first glance. Given our distributed model, in which individual units and staff are responsible for uploading and describing their own content, overly complex metadata represents a serious impediment to consistent adoption for graphic design project files.
This review project will reduce the barriers to sharing by streamlining description, upload and searching for files. Some fields might be "nice to have", but are they essential to share photos? Are they necessary to describe most graphic design project files in Information Production and City Planning? We will consider the benefits of each metadata field against the staff resources required to complete them.
Principles to consider when evaluating metadata fields to hide or remove:
Fields with no current functionality. Example: Records Classification Code. This was included anticipating lifecycle management, but was not budgeted for in our first phase. The field can be hidden. It may be reused for administrators only at a later date, if we choose to implement.
Fields that are unused. Example: master/source file location. Intended to capture the location of high-resolution master video files, this field has seen limited use with only a small set of videos uploaded. Managing the master-derivative file relationship is a larger issue that requires an approach across all asset types. The field can be hidden.
Fields that duplicate information available in other systems. Example: Creator contact info. Static contact information stored in DAL becomes less useful over time as staff move to new positions or leave the City. City staff contact information is also available from our email system. This field can be hidden.
Fields that are not needed for a user group's primary content. Example: Date(s) of Creation. This Archives field provides space for a variety of date formats when the actual date the photograph was shot is unknown. A sample value might be ca. 1910. This is important descriptive information for Archives, but not needed for groups whose content is born-digital and have another field with a validated timestamp format. This field can be hidden for non-Archives groups. It may be made visible to other groups when needed for search, as part of a future customization.
Fields that are only required for specific asset types. Example: Related Images. This field is only used when Consent Forms or Client Request Forms are uploaded and linked to their related images. It can be made visible only when those asset types are selected.
These principles should help guide our work to simplify our system and lay the groundwork for expanded adoption. In my next post, I will examine options to improve the remaining core fields and controlled lists.
When the system went live in 2011, it incorporated the requirements of four different business units. During the development process, metadata fields were added anticipating future functionality or to create an exhaustive list of descriptive information. The list grew as each group identified what seemed to be unique details or processes. The result was a fairly large set of metadata (50 fields!). Before launch, we reviewed the overal set and developed a custom profile for each group. Here's an example, from our Photo Video unit:
You can imagine that this list might be somewhat daunting for new users! Keep in mind that some fields are left blank for certain files, and some are automatically captured.
"Make it simpler"
If all our staff feedback could be reduced into a single idea, this would be it. Even a seasoned cataloger might be challenged by our set of metadata at first glance. Given our distributed model, in which individual units and staff are responsible for uploading and describing their own content, overly complex metadata represents a serious impediment to consistent adoption for graphic design project files.
This review project will reduce the barriers to sharing by streamlining description, upload and searching for files. Some fields might be "nice to have", but are they essential to share photos? Are they necessary to describe most graphic design project files in Information Production and City Planning? We will consider the benefits of each metadata field against the staff resources required to complete them.
Principles to consider when evaluating metadata fields to hide or remove:
Fields with no current functionality. Example: Records Classification Code. This was included anticipating lifecycle management, but was not budgeted for in our first phase. The field can be hidden. It may be reused for administrators only at a later date, if we choose to implement.
Fields that are unused. Example: master/source file location. Intended to capture the location of high-resolution master video files, this field has seen limited use with only a small set of videos uploaded. Managing the master-derivative file relationship is a larger issue that requires an approach across all asset types. The field can be hidden.
Fields that duplicate information available in other systems. Example: Creator contact info. Static contact information stored in DAL becomes less useful over time as staff move to new positions or leave the City. City staff contact information is also available from our email system. This field can be hidden.
Fields that are not needed for a user group's primary content. Example: Date(s) of Creation. This Archives field provides space for a variety of date formats when the actual date the photograph was shot is unknown. A sample value might be ca. 1910. This is important descriptive information for Archives, but not needed for groups whose content is born-digital and have another field with a validated timestamp format. This field can be hidden for non-Archives groups. It may be made visible to other groups when needed for search, as part of a future customization.
Fields that are only required for specific asset types. Example: Related Images. This field is only used when Consent Forms or Client Request Forms are uploaded and linked to their related images. It can be made visible only when those asset types are selected.
These principles should help guide our work to simplify our system and lay the groundwork for expanded adoption. In my next post, I will examine options to improve the remaining core fields and controlled lists.
Wednesday, 22 August 2012
Reuse - the beauty of embedded metadata
My Digital Asset Library (DAL) plans for this year included improving our capacity to manage working files and making better use of embedded metadata. These two goals came together as several staff in Information Production and City Planning participated in a working files pilot. Their feedback made clear we need to make it easier to upload, describe and reuse files. Both Information Production and City Planning, Graphics & Visualization have similar business processes, creating new design projects using Adobe Illustrator and InDesign, linked to the raw graphic & image files, and often reusing existing content.
Pilot participants noted that applying detailed metadata to the many distinct files that make up a single design product could be very time consuming. This process is quite different from uploading a batch of event photos, which all have the same metadata. We decided to re-examine how we can simplify the process of uploading and tagging files.
As a first step, we focused on making it easier to reuse files and metadata. If an event photo or graphic has already been described in DAL, we wanted that information to stay with the file once downloaded. It became clear we needed to develop an embedded metadata standard. Using Adobe's XMP technology, embedded metadata allows descriptive information (such as creator or keywords) to be written directly in the file and be read and written by different compatible applications. The first implementation of the standard will automatically apply metadata to files on download from DAL. This will save time since the files will not need to be described again if they are modified, reused and/or uploaded.
Over the summer I've worked with representatives from each business unit to develop our embedded metadata standard. I'm pretty happy we were able to identify a core set that everyone could agree on. Taking the time to debate the implications of choosing particular standards and mappings was very useful to gain consensus. Throughout the process I emphasized that this standard was our first version and not set in stone. It will change as we gain more experience and our requirements evolve. I think acknowledging the provisional nature of this particular set of metadata properties was very helpful.
We were able to build on existing mappings used to embed metadata in Archives' photos prior to upload into DAL. Looking outside the City, the Smithsonian Institution provided excellent perpective and advice with their Basic Guidelines for Minimal Descriptive Embedded Metadata in Digital Images.
We've identified 16 fields that can be embedded. Not all fields are used by all participating groups. Some are interoperable with the Dublin Core Metadata Standard, the City of Toronto Descriptive Standard and IPTC (the default fields used in Adobe CS products), while some are DAL custom fields.
We are now working to secure funding for professional services to implement our standard in DAL. Working closely with the business representatives, I have a much better understanding of their needs. Using this standard for embedding metadata in downloaded files is really a first step towards an improved model for managing working files. We will continue to plan further improvements to our metadata creation and uploading model to drive adoption, file reuse and effective search.
Pilot participants noted that applying detailed metadata to the many distinct files that make up a single design product could be very time consuming. This process is quite different from uploading a batch of event photos, which all have the same metadata. We decided to re-examine how we can simplify the process of uploading and tagging files.
As a first step, we focused on making it easier to reuse files and metadata. If an event photo or graphic has already been described in DAL, we wanted that information to stay with the file once downloaded. It became clear we needed to develop an embedded metadata standard. Using Adobe's XMP technology, embedded metadata allows descriptive information (such as creator or keywords) to be written directly in the file and be read and written by different compatible applications. The first implementation of the standard will automatically apply metadata to files on download from DAL. This will save time since the files will not need to be described again if they are modified, reused and/or uploaded.
We were able to build on existing mappings used to embed metadata in Archives' photos prior to upload into DAL. Looking outside the City, the Smithsonian Institution provided excellent perpective and advice with their Basic Guidelines for Minimal Descriptive Embedded Metadata in Digital Images.
We've identified 16 fields that can be embedded. Not all fields are used by all participating groups. Some are interoperable with the Dublin Core Metadata Standard, the City of Toronto Descriptive Standard and IPTC (the default fields used in Adobe CS products), while some are DAL custom fields.
We are now working to secure funding for professional services to implement our standard in DAL. Working closely with the business representatives, I have a much better understanding of their needs. Using this standard for embedding metadata in downloaded files is really a first step towards an improved model for managing working files. We will continue to plan further improvements to our metadata creation and uploading model to drive adoption, file reuse and effective search.
Thursday, 19 April 2012
City of Toronto's Digital Asset Library - importing trends #DAM
Everyone loves measuring performance with statistics right? At this point, we don't currently have a standard set of reports that can be automatically output from our Digital Asset Library (DAL). I have to manually run a series of searches and compile information onto a spreadsheet, then output a chart. Not the most elegant of solutions, but does provide a bird's eye view of our progress so far:
Observations:
Photo Video unit is by far the most active uploader into DAL. This is not surprising because they were the originating unit of the DAL project, and the project requirements were tailored most closely to their needs. They have less complex file types (typically TIFFs & JPEGs) than some of our other participating groups. They also produce a large volume of photographs of City events which can be quickly tagged and uploaded as batches. To their credit, they have been dedicated uploaders, typically importing hundreds of photos in batches each week.
Both Graphics & Visualization, City Planning and Information Production, City Clerk's Office have a steady but moderate growth in their files uploaded. Specific staff have been using DAL for sharing completed projects (as PDFs). An individual design project naturally takes more time to complete than a single event photo, and therefore there are fewer overall files than Photo Video. However, these numbers also make clear that we must continue expanding our pilot managing more complex working Adobe Illustrator & InDesign files with placed art, leading to full adoption throughout these units. These files take more time to upload and tag, as each individual working file has unique metadata. We are currently planning an embedded XMP metadata project which should reduce workload when reusing working files in new projects.
Archives are using DAL to upload batches of JPEG access copies, which have embedded XMP metadata. The fall-off in imports in early 2012 reflects some challenges in updating application components that allow DAL to read embedded metadata on import. There is a learning curve for sustaining and managing new systems and we are certainly experiencing this. We have a plan to resolve this issue in the near future, so batch imports can resume later in 2012.
This snapshot of DAL uploads reinforces the need for better reporting, which is essential for identifying trends and areas for improvement. We are planning to upgrade our reporting capabilities in 2013.
Observations:
Photo Video unit is by far the most active uploader into DAL. This is not surprising because they were the originating unit of the DAL project, and the project requirements were tailored most closely to their needs. They have less complex file types (typically TIFFs & JPEGs) than some of our other participating groups. They also produce a large volume of photographs of City events which can be quickly tagged and uploaded as batches. To their credit, they have been dedicated uploaders, typically importing hundreds of photos in batches each week.
Both Graphics & Visualization, City Planning and Information Production, City Clerk's Office have a steady but moderate growth in their files uploaded. Specific staff have been using DAL for sharing completed projects (as PDFs). An individual design project naturally takes more time to complete than a single event photo, and therefore there are fewer overall files than Photo Video. However, these numbers also make clear that we must continue expanding our pilot managing more complex working Adobe Illustrator & InDesign files with placed art, leading to full adoption throughout these units. These files take more time to upload and tag, as each individual working file has unique metadata. We are currently planning an embedded XMP metadata project which should reduce workload when reusing working files in new projects.
Archives are using DAL to upload batches of JPEG access copies, which have embedded XMP metadata. The fall-off in imports in early 2012 reflects some challenges in updating application components that allow DAL to read embedded metadata on import. There is a learning curve for sustaining and managing new systems and we are certainly experiencing this. We have a plan to resolve this issue in the near future, so batch imports can resume later in 2012.
This snapshot of DAL uploads reinforces the need for better reporting, which is essential for identifying trends and areas for improvement. We are planning to upgrade our reporting capabilities in 2013.
Monday, 26 March 2012
digital asset management at the City of Toronto - priorities for 2012 #DAM
2012 is a year of ongoing improvements and next phase planning for our Digital Asset Library. We are focusing on improving our standards and processes around working files, embedded metadata and copyright. We are also gathering requirements to build a business case for our next phase - incorporating feedback, functional needs as well as necessary application and environment upgrades to support growing numbers of users and content.
What has really struck me over the last year I've been working on this project is the great interest from City staff in better image management and reuse. Staff really do recognize the value of sharing assets between units. In 2012, we'll be laying the groundwork for improved functionality, new partnerships and better sharing of resources. Here's an overview of DAL priorities, as I see them, over the next year. Your feedback is welcome.
What has really struck me over the last year I've been working on this project is the great interest from City staff in better image management and reuse. Staff really do recognize the value of sharing assets between units. In 2012, we'll be laying the groundwork for improved functionality, new partnerships and better sharing of resources. Here's an overview of DAL priorities, as I see them, over the next year. Your feedback is welcome.
Wednesday, 11 January 2012
DAM project feedback from #Toronto Urban Design staff #EIM #OpenGov #ToCouncil
Last year, I had the opportunity to introduce our Digital Asset Library project to the City Planning Urban Design team at a staff meeting in Etobicoke. Our first phase is a pilot with a smaller unit that is part of Urban Design, the Graphics and Visualization unit, but we wanted to provide an update to the larger team. I sat in on the full meeting, and it was fascinating to get a big picture view of design and planning projects underway. I was intrigued by work to connect South Etobicoke and Mimico with the waterfront, and integrate a growing Humber College into the surrounding community and historic campus.
There were some great questions during my presentation and many staff took the time to speak to me afterwards with their thoughts. A few key issues that came out of our conversations:
Friday, 30 December 2011
digital asset management inside the City of Toronto #TOcouncil #opengov
Recently, David Eaves' post on the future of academic research got me thinking again about the benefits of openness and collaboration. Eaves praises a British Columbia scientist, Rosie Redfield, for blogging her way through an ongoing experiment. In the process, she's encouraged international feedback and provided rare insight into her thought processes as a scientist. Redfield stands out because she is breaking with protective scholarly publishing traditions that dampen collaboration.
 |
| The Digital Asset Library is a an application for managing images inside the City of Toronto |
Recently, David Eaves' post on the future of academic research got me thinking again about the benefits of openness and collaboration. Eaves praises a British Columbia scientist, Rosie Redfield, for blogging her way through an ongoing experiment. In the process, she's encouraged international feedback and provided rare insight into her thought processes as a scientist. Redfield stands out because she is breaking with protective scholarly publishing traditions that dampen collaboration.
Subscribe to:
Posts (Atom)
