Today's Toronto Star includes this perfect example of why we need good practices around how we manage and reuse digital photographs:
Woman sues after her picture used in HIV ad.
It appears this woman was the subject of a photo shoot several years ago. The photographer then turned around and sold the photographs via Getty Images, without getting consent, a release or authorization from her subject. To make matters worse, Getty has a clause in their license stating that "using an image in connection with an unflattering or controversial subject requires a disclaimer statement that: (1) licensed material is being used for illustrative purposes only, and (2) any person depicted in the licensed material is a model." It doesn't appear this was followed in the New York State Division of Human Rights ad.
Yikes! Make sure you manage consent forms and permissions related to your digital photographs, provide the right level of security and reduce the risk to your company or organization.
Friday, 27 September 2013
Thursday, 9 May 2013
Openness and reuse of digital photographs
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".
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.
Subscribe to:
Posts (Atom)
