WO2006125271A1

WO2006125271A1 - A digital asset management system

Info

Publication number: WO2006125271A1
Application number: PCT/AU2006/000703
Authority: WO
Inventors: Ashley John Flynn; Brendan Alexander Michael Read
Original assignee: Damit Australia Pty Ltd
Priority date: 2005-05-27
Filing date: 2006-05-29
Publication date: 2006-11-30

Abstract

A digital asset management system comprising a database capable of storing a plurality of digital assets, and a taxonomy comprising at least one grouping of related keywords, wherein each digital asset is associated with at least one keyword selected from the taxonomy, and the digital asset is retrievable by searching one of the at least one keyword and any other related keywords contained in the grouping.

Description

A DIGITAL ASSET MANAGEMENT SYSTEM

Field of the Invention

The present invention relates to a digital asset management system, and, particularly but not exclusively, to a digital asset management system for storing and retrieving digital images .

Background of the Invention

The management of digital assets, such as electronic images, is a pressing issue. A number of stand alone software applications and Internet based services provide the ability to store and categorise digital assets.

However, such systems are inherently clumsy, because they rely on the user to provide accurate and consistent categorisation information.

Most software applications for categorising electronic images allow a user to associate one or more keywords with the image. However, different users may use different keywords to categorise the same electronic image .

For example, a first user may take a photograph of a blue Ford sedan, and may use the words blue", "sedan" and "Ford" to categorise the image. A second user, not knowing that the first user has used the terms "blue" , "sedan" and "Ford" to categorise the image, may try to search for the image using the terms "car" and "vehicle" . As might be expected, the use of the terms "car" and

"vehicle" to search for an image classified under the terms "blue" , "sedan" and "Ford" would result in the second user not finding the image .

Therefore, keyword categorisation is generally an inefficient manner in which to categorise digital assets, as it relies on all users having some common knowledge regarding the likely terms used to categorise the digital assets . Summary of the Invention

In accordance with a first aspect the present invention provides a digital asset management system comprising a database capable of storing a plurality of digital assets, and a taxonomy comprising at least one grouping of related keywords, wherein each digital asset is associated with at least one keyword selected from the taxonomy, and the digital asset is retrievable by searching one of the at least one keyword and any other related keywords contained in the grouping.

In an embodiment, the taxonomy is organized into a hierarchy of parent keywords and children words, wherein any children keywords have a narrower definition that the parent keywords .

In an embodiment, the taxonomy is structured in the form of a directed graph.

In an embodiment, the directed graph is arranged in a descending order using the Levenstein distance between the related words .

In an embodiment, the at least one keyword is stored as meta-data in the database.

In an embodiment, the digital asset management system further comprises a means to vary the taxonomy.

In an embodiment, the digital asset may be associated with additional identifying data.

In an embodiment, the system further includes remote access means . In an embodiment, the remote access means is a web server capable of serving a web interface to an user.

In an embodiment, the digital asset is an electronic image .

In an embodiment, the electronic image is a photograph .

In accordance with a second aspect, the present invention provides a method of storing digital assets, comprising the steps of uploading a digital asset into a database, prompting a user to select at least one keyword to associate with the digital asset, and associating the keyword with the digital asset, wherein the keyword is chosen from a taxonomy comprising at least one grouping of related keywords, so that the digital asset may be searched using one of the at least one keyword and the at least one grouping of related keywords .

In accordance with a third aspect, the present invention provides a method of searching for a digital asset comprising the steps of prompting a user to select a keyword, wherein the keyword is associated to a grouping of other keywords and returning a list of digital assets which are associated with the keyword and ^"with the grouping of other keywords . In accordance with a fourth aspect, the present invention provides a digital asset management system capable of storing a plurality of digital assets, each digital asset being associated with at least one keyword, the at least one keyword being further associated with at least one other keyword, wherein the digital asset may be retrieved utilising one of the at least one keyword and the at least one other keyword.

Brief Description of the Drawings

Features and advantages of the present invention will become apparent from the following description of an embodiment thereof, by way of example only, with reference to the accompanying drawings, in which: Figure 1 is a diagram of a hardware configuration according to an embodiment of the present invention;

Figure 2 is a diagram of a software configuration according to an embodiment of the present invention;

Figures 3a and 3b are screen shots of a user interface according to an embodiment of the present invention;

Figure 4 is a directed graph word tree according to an embodiment of the present invention; Figure 5 is a flow diagram for uploading a file according to an embodiment of the preset invention; and

Figure 6 is a flow diagram of retrieving a record according to an embodiment of the present invention.

Detailed Description of the Preferred Embodiments

Referring to Figure 1, a Hardware configuration is shown for a digital asset management system according to an embodiment of the present invention. The Hardware configuration of Figure 1 is configured to facilitate access to the system by both remote and local users . In the embodiment described herein, the digital asset management software resides on a network server further comprising a web server and a database server. The server is networked to a plurality of users by way of a local network and/or the Internet. It will be understood that whilst the system software shown in Figure 1 resides on a networked server, the software is equally suitable for use on a stand alone personal computer, and may be arranged to run as a standalone software application rather than as a service on a server.

The digital asset management system of the present invention can be used to upload and retrieve any form of digital multimedia. However, the system is particularly suited for management of digital images and photographs . The system comprises an intelligent search engine for retrieving stored assets using a controlled-vocabulary taxonomy. Each keyword stored in the taxonomy can be associated with any number of parent (broader definitions) and child (narrower definitions) keywords. When a user searches for a stored record by entering a keyword, they are presented with matching and similar keywords, and also with associated parent and child keywords. Once a user selects a keyword from the results list the taxonomy search engine returns all files assigned to that keyword, as well as records assigned to child words of the chosen word. The system can cater for any number of recursive levels of association. In one embodiment, the levels of association are managed by a directed graph. This allows for more flexibility and more complex relationships than a simple "tree" structure. Referring now to Figure 2, the software applications of Figure 1 is further described. Input records are first stored in the XFS file system with any linked image information and metadata being stored in the SQL database . A PHP based back-end communicates with the SQL database and file system via Postgresql and the UNIX operating system to manipulate the data before the data is communicated to the software application. The second software application, also built with PHP, contains the basic functions and processes required to run the application. It also mediates between the back-end and the software modules/business logic.

The modules/business logic contains the graphical user interface (GUI) and additionally controls the functionality of user inputs. The modules are written in a combination of PHP and XML. An XML parser takes the XML output from the modules and turns it into HTML elements. A PHP based wrapper takes the HTML output and packages the HTML into JavaScript commands which are passed to the web browser. A JavaScript based view controller on the browser interprets the JavaScript commands it receives from the wrapper and displays the HTML on the screen in the way requested through the XML by the modules . The Browser-side JavaScript/Web interface works by splitting the screen into two frames. One frame (that takes 100% of the visible browser window) is the "mainframe" and contains all the objects visible to the user such as images, text, buttons (which takes etc) . A hidden frame called the "actionframe" (which takes up 0% of the visible browser window) receives the HTML from the wrapper and delivers it to the Browser-side JavaScript view controller. All user actions are captured in forms within the "mainframe" and submitted via the hidden frame back to the PHP modules on the server, which then act on the user input .

The interface uses Cascading Style Sheets (CCS) and JavaScript to display the information from the JavaScript view controller on the user's screen.

The system shown in Figure 2 allows a software application style interface to be delivered via a web browser, without having to reload pages one-by-one to carry out tasks as is normally required by online web applications.

The graphical user interface (GUI) is further characterised with reference to Figure 3. The GUI comprises a plurality of dynamically generated, resizable windows. Disposed on the leftmost part of the screen is a taxonomy window, facilitating entering and searching of keywords. The taxonomy comprises a list of pre-defined keywords that can be updated at any time. External taxonomies can also be imported into the system to meet the requirements of a specific user. The window disposed in the middle of -the screen

(records window) provides a visual display of all records matching the keywords selected in the taxonomy window. The records window can be configured to display records according to physical size, category etc. The selected items window (disposed on the top right part of the user interface) shows a visual image of the currently selected record from the records window. Directly beneath the selected items window is a preview window further provided to display a currently selected record. It should be noted that the configuration of these windows is not in any way fixed and may be customised to meet the requirements of the user.

The GUI, in an alternate embodiment, communicates with the server using a JavaScript and ActiveX function known as "XMLHTTPrequest" . This incorporates the AJAX method of client and server communication. This may be used instead of the "hidden frame" communication method that is described herein. By way of example, and with reference to the flow charts of Figures 5 and 6, a process for uploading and retrieving files according to an embodiment of the present invention will now be described. In these embodiments the digital asset management system will be referred to as 'Got It' . At Step Sl, a user logs into the ^λGot It' system via a web browser. Once logged in, the user can upload a file by clicking an upload button. Next, the user chooses whether to add metadata to the uploaded file. For example, a user might like to enter a caption or a timestamp for a particular file. This metadata can be added to a particular file during Step S2 of the current embodiment . At Step S3 , the user chooses a method by which to upload the file. Upload methods may include Java Upload Applet, Serverside Upload and HTTP file upload.

When the upload method has been decided, the user selects the files to be loaded into the system (Step S4) . Uploaded files (hereinafter referred to as records) are then processed in the ^xGot It' archive, and displayed to the user on a GUI (Step S5) . A user then selects a keyword from a predefined list (taxonomy) and assigns it to the selected records (Step S6) . Alternatively the user may wish to assign a keyword to a group of records. For example, in one embodiment, the user might upload an arbitrary group of images from a wedding shoot and assign them to a group called "The Williams' Wedding Shoot". Once the user has assigned all records to a keyword the upload process is complete (Step S7) .

A method for retrieving records is shown by way of Figure 6. In Step S8, a user logs into the ^λGot It' system via their web browser. Once logged in, the user enters a whole or partial search word describing an attribute of the desired record in a taxonomy search engine (Step S9) . At Step SlO, the system returns a list (results list) of words matching the whole or partial word, as well as words that are spelled similarly or sound similar when spoken. In this embodiment, the system also returns a secondary level of results, comprising words having narrower or broader definitions (parent and child words) , related words and words that could be ^λused in place of the words returned in the results list (Step SIl) . The user can browse the secondary level of results by clicking on a word returned in the results list (Step S12) . In one embodiment, the results are displayed in descending order using a Levenstein distance (number of different characters) between the search word and the result word. This ensures the closest word to the search word appears at the top of the list. Once a user finds a desired word, the user selects the word and clicks on a ^xfind records' button (Step S12) . At Step S13, the system searches the database for all records that are assigned to that word and all records that are assigned to child words of that word. The system can cater for any number of recursive search levels associated with child words. Once all matching records have been found they are retrieved and displayed on the user's display (Step S13) .

Multiple taxonomies may be created within the system. Moreover, each taxonomy is associated with a set of permissions, the permissions being unique to each user. The permission set defines what each user may do with each taxonomy. This may include whether a user can view, edit or delete the taxonomy, or view, edit or delete words in the taxonomy.

According to an embodiment of the present invention, the system also provides various levels of access control to areas of the system unrelated to the taxonomy. For example, users and groups could be allowed or denied permission to perform certain tasks, e.g. to add or remove records, edit metadata etc. Access control could also be restricted to particular records. According to an embodiment of the present invention, administrators could allow or deny a particular user from downloading or viewing the thumbnail of a chosen record. Furthermore, certain module components of the software could be turned on or off for specific users, thereby allowing - S - administrators to control access to selected parts of the software application.

According to another embodiment, the system allows users to store multiple file types and versions of records. For example, the multiple file types could allow users to store a large digital RAW file, a color-corrected

TIFF and a web-ready JPEG all related to the same image under the one Record. The system could also allow users to store multiple versions of a stored record. In this way users would be allowed to roll back and forward chronologically through changes they have made to each record.

Searching a tree of words for a resulting assigned image or images can be a very time consuming process. The following method is incorporated into an embodiment of the system to make the searching process almost instantaneous. As words from a taxonomy in the system are assigned to an image, the data is stored and searched in a series of tables. In the example, a number of tables exist in the database. The first table (Table 1) is a list of taxonomy words. The second table (Table 2) is a list of associations between words, in a "parent-child" format.

Table 1 - Taxonomy Words

Table 2 - Word Relationships Table

The embodiment of the present invention creates a further table with four columns . The first two columns are "record_id" (an identity, normally numerical, that is assigned to every record in the database) , and "word_id" (an identity, again numerical, which is assigned to every word in the taxonomy) .

The table also holds two additional values in two additional columns, namely: • originating_word_id - A record of the directly assigned keyword that caused this word to be entered into the table . • assigned_word - A Boolean value (i.e. ^Λt' for true and ^λf for false) which is set to true if the word is a directly assigned keyword and to ^xf if the word is not a directly assigned keyword.

The manner in which a word is assigned to a record is outlined below. Firstly, an entry is made into the words_records table for the assigned word. For example, "Brown" which is word_id 6 (according to Table 1) would appear as follows :

In this instance, record_id is simply because this is the first record in the table. The originating_word_id is not used, as "Brown" is not the "child" of any other word so it is set to the same value as word_id, and assigned_word is set to ^λt' because this is a directly assigned word. Secondly, it is necessary to determine which other words would find this record if a cascading tree search were run. An entry is made for each word, but the record_id is set to ^λl', the word__id to the id of the given word, originating_word_id to ^X6' because it is the directly assigned word that caused each new entry to appear .

Subsequently, assigned_word is set to ^Λf for these new entries, as they are not actually words directly assigned to the record, just words that would find this record because of the tree relationship with the assigned word. This is shown in Table 3 below:

Table 3 - A Completed Table

By constructing the table in this manner, a number of editing, searching and deleting functions are simplified. For example :

• De-Assign Word from Record: To delete word 6 from record 1 to remove the assigned word and any associated words that originated from assigning word 6. Delete * from words_records where originating_word_id = ^v6" and record__id = ^λi';

• Find Words Assigned to a Record: Returns a list of ids of directly assigned words for record 1 only. select unique originating_word__id from words where record_id = ^xl' ;

• Add Word: Insert word entry into words table. Follow 'Add relationship to tree' below to join the word to its parents.

• Add Relationship to Tree: Adding Word as Child: Add entry in word_relationships to reflect the new relationship. This has no effect on word searches so no need to update anything else.

Adding Word as Parent: Add entry in word_relationships to reflect the new relationship. Search words_records for entries for the effected child. Get the resulting record_ids . Put in a new entry for the new parent word as an associated word for each record_id.

• Delete Word: Delete entry in word table for word. Follow ^vDelete relationship from tree' to detach the word from its parents and children.

• Delete Relationship from Tree: Search the words_records table the word_id of the child or parent affected by the delete (it doesn't matter which) . Return the record_ids and originating_word_ids matching the search. Delete all these matching entries from words_records, but only where assigned_word = ^λf, unless the target word to be deleted is itself an assigned word (assigned_word = ^λt') .

If we didn't just delete the actual associated word, for each record_id returned previously, now recalculate the words__records entries for the word matching the originating_word_id, as per the process for assigning words. This updates the associated entries for the specific word on the specifically affected records only.

• Update Record Count in Words Table: Fill no_records column in words table with result of: count rows of: select unique record_id from words_records where word_id = ^x (word id to search for) ' . • Find Out How Many Records Would be Found if we did a Tree-Search on (X Word) : Count the number of unique record_ids returned that have word_id of (x word) in words_records table • Search for Records for a Given Word: For example, find all records for word 5. select unique record_id from words_records where word_id = ' 5 ' .

Therefore, as can be seen, using the table/database structure outlined above, a number of searching, editing and deleting features are simplified.

It will be understood that the digital asset management system also includes a number of other features including, but not limited to, the following: • Collections - Groups of Records, sometimes known as "Albums" in other software . Records may belong to any number of Collections. Handy for grouping images together for jobs, clients, etc.

• Serverside Upload/Download (includes local drives, flash cards, firewire/USB drives and FT/NFS/Samba upload) - Images may be uploaded to shared folder on the server via FTP, Samba (Windows directory sharing) or NFS (UNIX directory sharing also supported by OSX) . These are the fastest image upload methods available. Images in the shared directories or on eternal card readers and drives can be catalogued directly, as opposed to uploaded via the browser as with HTTP upload. Images can also be downloaded to shared directories available via FTP NFS/Samba. • HTTP File Upload/Download - For users in remote locations, behind restrictive firewalls or for any reason unable to use FTP upload/download may use direct file uploading/downloading through the web browser interface. This is known as HTTP file transferring. • Edit Metadata - Collections, Records, Assets and Versions all have metadata associated with them. The metadata may be automatically generated from IPTC/EXIF or file info such as resolution, size, data taken, etc. Or it may be user generated after the image is catalogued such as caption, copyright information, etc. Common Image Formats and RAW file support. Around 80+ common file formats are supported such as JPEG, TIFF, PSD, etc. RAW file support for top digital camera brands such as Canon and Nikon are also supported.

• HTTPS Secure Web Browser Access - Accessing information via a web browser can be insecure, especially when you are using an untrusted network such as an Internet Cafe or Hotel Internet connection. To overcome this problem we use HTTPS. HTTPS (SSL security through the HTTP protocol) is a secure method of accessing information through a web browser. It is used widely for secure online transactions such as Internet shopping and Internet Banking.

• Undelete Assets (""Empty Trash Can" Style System) - Deleted Records and Assets are stored in a "Trash Can" rather than removed. These will not be removed until the user chooses to empty the Trash Can, as with file deletion on Windows or Mac OSX.

• User/Groups Permissions - Each use on the system is given a unique login name and password. Users can then be assigned to groups. Each Record and Asset is protected by a security model that controls which users and groups can access each image and what they can do with it. For example, a user may have permission to view only previews of a particular image, but not download the entire original asset .

• Asset Versioning ~ A new version o an asset can be uploaded, replacing the old version. All the old versions of a given asset are stored either for specified time or they may be deleted manually. This help protect against the accidental destruction of an asset, and also allows the user to see the history of revision to a given asset.

^■ • Search - All metadata, file info, IPTC and EXIF data in the database can be searched. • Admin Control (Hardware and Software) - Administrators are able to control the server hardware through the web interface. This include start-up, shutdown, system monitoring and backups. • Image Conversion - Assets can be converted between most of the supported file formats.^' For example this would allow a user to download an asset store on the server as a 24MB TIFF as a 40OkB high-compression preview JPEG. • Thumbnail and Preview Image Manipulation - Thumbnails and Previews can be rotated and colour corrected at the click of a button.

• Backups - All assets and the database can be backed up either on to removable hard drive volumes or tape drives. The removable hard drive volumes are the cheapest and fastest backup method available for catalogues of images under 2 Terabytes . The backup system may include a tape drive or any other suitable storage device in place of a removable hard drives for data protection. The backup system may store data in an encrypted or compressed format to enhance space efficiency and security.

• IPTC/EXIF Import ~ As an image is catalogued, its IPTC and EXIF info can be captured and added to database metadata fields automatically. For example this would allow photographers in the field to use a program such as PhotoMechanic to add caption info to the images IPTC info. This caption could then be automatically imported into the caption field in the database as the image is catalogued.

• IPTC/EXIF View - IPTC and EXIF info stored in assets (separate from the database) can be viewed at any time.

• Email Module - The server and the software have the ability to send emails. This allows things such as statistics reports to be email to users or critical error messages (like hard drive failure reports) to be emailed to admins . • Logging - All actions such as file uploads, downloads, searches, etc are logged for statistics collection.

• IPTC/EXIF Export - As images are downloaded, user-specified fields of information within the database may be added to an images embedded IPTC/EXIF info.

• CD/DVD Burning - Users can order images to be burned on CD. The images are downloaded to a temporary- folder (one per request) and the system administrator can burn the images to CD/DVD either on the server DVD drive or their own desktops .

• Statistics Collection/Reporting - The system logs can be processed to create useful reports on system usage. Useful information can be determined such as how much each image is being used, who are the most active users, how much hard drive space each user is taking up with their images, etc.

• Documentation (Full User Manual) - Full printed user documentation. • Rollback Metadata ("Undo") - An "Undo" button allows users to undo changes they make by mistake.

• DAM Import - Images and metadata from other popular DAM systems can be imported.

• Save Searches - Search criteria (what was being searched for, rather than the search results themselves) can be saved. This is useful for recalling searches users frequently run and do not want to have to retype each time.

• Email (Advanced Features Such as Email Assets) - The email system may be used as a download method. In the case where even HTTP downloading cannot be used, assets may be emailed to a user instead at their request.

• Image Watermarks - Images for preview only by certain users may be watermarked automatically with no need for a watermarked version to be uploaded.

• Online Ordering - Online ordering of images through a collection basket style system. This includes the ability to take credit card and other payment details automatically.

• License Agreement Management - Users will be required to digitally sign license and usage agreements when downloading images with such agreements attached.

• MD5 Checksums - As assets are added to the database, their data is scanned and an "MD5 checksum" is stored for each asset. This is like a unique fingerprint that tells the system what the file should look like. If the data is corrupted or edited in some way, the system can see the MD5 checksum for that file has changed, and alert the system administrator or file owner.

• Taxonomy Import/Export - Taxonomies (or category trees) can be imported from popular taxonomy standards (such as the Australian Pictorial Thesaurus) or other DAM systems .

• Asset Check In/Checkout - To prevent two users editing the same asset, assets may be checked in and out. An asset that has been checked out can be edited without that user checking it in again.

• Multiple Language Support - All text in the user interface is stored in a language file. Language files can be created for any language . The interface can then appear in the language required. Each user can specify which language they wish to use.

• Change Approval System - Changes to metadata, collections, records, assets, versions, taxonomies, etc by certain users can be blocked until an administrator approves those changes . • Slideshow - A useful way to preview images in a collection. A slideshow will show each images for a preset length of time before moving on to the next image.

• Image Rating/Reviews (Amazon Style) - Users can leave ratings and reviews for images in a format similar to Amazon.com. These reviews and rating can be sent to image owners, or be visible to all users. • AI Image Searching - An advanced AI image searching system allows users to search the database for images that look similar to an image they supply.

• Forums - Forums for registered users allow for discussions and project collaboration.

• Live Chat and Messaging - Users are able to send each other messages through the web interface. Users logged in to the system at the same time are able to conduct live text chat with one another. • License Control - Licenses may be assigned per image and per user. Licenses define the permitted usage of a particular image by a particular user. Licenses may include details such as Duration (star and end dates) , Exclusivity, Location of image usage (Geographical region), Modification rights, Usage (Advertising,

Brochure, Newspaper, TV, Film, etc) . A License generally includes all the legal terminology as shown to the user at the time the license was digitally signed by the user. The legal terminology is stored in the System and may be modified by the System owner. A reminder notice is sent to the image owner and license holder a set time before the expiry of the license, and again when the license expires. The reminder notice may include details about how the license holder may renew the license and what fee is associated with the renewal. License control may be incorporated with the online vending system, such that users of images must digitally sign a license defining the acceptable usage of the image before their purchase is approved and before the System will give them access to that image .

It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

Claims

THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS:

1. A digital asset management system comprising a database capable of storing a plurality of digital assets, and a taxonomy comprising at least one grouping of related keywords, wherein each digital asset is associated with at least one keyword selected from the taxonomy, and the digital asset is retrievable by searching one of the at least one keyword and any other related keywords contained in the grouping.

2. The digital asset management system of Claim 1, wherein the taxonomy is organised into hierarchy of parent keywords and children words, wherein any children keywords have a narrower definition that the parent keywords.

3. The digital asset management system of Claim 1 or Claim 2 , wherein the taxonomy is structured in the form of a directed graph.

4. The digital asset management system of Claim 3, wherein the directed graph is arranged in a descending order using.

5. The digital asset management system of any one of

Claims 1 to 3 , wherein the at least one keyword is stored as meta-data in the database.

6. The digital asset management system of any one of Claims 1 to 4 , further comprising means to vary the taxonomy.

7. The digital asset management system of any one of Claims 1 to 5, wherein the digital asset may be associated with additional identifying data.

8. The digital asset management system in accordance with any one of the preceding claims, wherein the system further includes remote access means.

9. The digital asset management system in accordance with Claim 7, wherein the remote access means is a web server capable of serving a web interface to an user.

10. The digital asset management system in accordance with any one of the preceding claims, wherein the digital asset is an electronic image.

11. The digital asset management system of Claim 9, wherein the electronic image is a photograph.

12. A method of storing digital assets, comprising the steps of uploading a digital asset into a database, prompting a user to select at least one keyword to associate with the digital asset, associating the keyword with the digital asset, wherein the keyword is chosen from a taxonomy comprising at least one grouping of related keywords, so that the digital asset may be searched using one of the at least one keyword and the at least one grouping of related keywords .

13. A method of searching for a digit asset comprising the steps of prompting a user to select a keyword, wherein the keyword is associated to a grouping of other keywords and returning a list of digital assets which are associated with the keyword and with the grouping of other keywords .

14. A digital asset management system capable of storing a plurality of digital assets, each digital asset being associated with at least one keyword, the at least one keyword being further associated with a least one other keyword, wherein the digital asset may a retrieved utilising one of the at least one keyword and the at least one other keyword.