Enabling reuse of City of Toronto digital photographs was an early justification for the development of our Digital Asset Library program. It is embedded in our approved mandate, to 'provide a digital asset management platform enabling collaboration, sharing and reuse of digital assets".
Thursday, 9 May 2013
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 |
Friday, 9 November 2012
Not quite there: fun with Google Image recognition and search
There's something playful about the way researching one topic often leads to new insights on another. While attempting to track down copyright information for a test file, I decided to try out some of Google's newer image recognition and search capabilities, such as the browser-based Google Image and the mobile app, Google Goggles.
The underlying idea is pretty wonderful – instead of trying to think up just the right search terms, simply snap a picture or upload an existing image, and the magic of Google will find images “like” it. This could be great tool for designers who may be looking for similar but slightly different images to fit into a specific design project. Could the promise of algorithmic image recognition reduce the need to apply keywords and descriptions to our images?
The underlying idea is pretty wonderful – instead of trying to think up just the right search terms, simply snap a picture or upload an existing image, and the magic of Google will find images “like” it. This could be great tool for designers who may be looking for similar but slightly different images to fit into a specific design project. Could the promise of algorithmic image recognition reduce the need to apply keywords and descriptions to our images?
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.
Subscribe to:
Posts (Atom)
