WO2004102421A1

WO2004102421A1 - Mechanism for storing different versions of information items

Info

Publication number: WO2004102421A1
Application number: PCT/FI2003/000365
Authority: WO
Inventors: Jukka-Pekka Salmenkaita; Tapio Tallgren
Original assignee: Nokia Corporation
Priority date: 2003-05-13
Filing date: 2003-05-13
Publication date: 2004-11-25
Also published as: EP1623340A1; AU2003227787A1

Abstract

Versions of information items are stored as views. Each view has a common portion and one or more unique portions. For each information item there is a first-order information tuple (200) and one or more nth order information tuples (210, 215 ). A metadata (201) field describes the information tuple. A reference count field (202) counts references to the first-order information tuple. A content field (203) indicates the common portion. Each nth order information tuple comprises a metadata field (211, 216 ) for the unique portions, a reference count field (212, 217 ) and a reference field (213, 218 ) to a higher-order information tuple. A reference-tracking system increments or decrements the reference field of an information tuple when references to the information tuple are created or deleted. An information tuple is normally deleted when its reference field becomes zero, but is kept for some time if there are external links (251) to it.

Description

MECHANISM FOR STORING DIFFERENT VERSIONS OF INFORMATION ITEMS

BACKGROUND OF THE INVENTION

The invention relates to storage of electronic information that must be accessible to several users and in different versions. US patent 5813008 to Max Benson et al. discloses a technique for single-instance storage of information, in which electronic mail messages have a unique portion and a common portion that is the same for multiple mail messages. The common portions are stored only once. Each common portion is assigned a globally unique single-instance identifier. Each unique portion of a mail message stores the single-instance identifier of the associated common portion. A reference count, stored with the common portion, reflects the number of unique portions associated with the common portion. When a mail message is created or distributed, the single-instance identifier of the common portion is used to ensure that multiple copies of the common portion are not stored.

The reference count is thus a crucial item in the Benson et al. technique. While the reference count solves the problem underlying the Benson et al. invention, it may create problems of its own. Such a reference count-based technique is somewhat inflexible. Moreover, the reference count may not re- fleet reality if information items, such as images, are released outside of a centrally-administered system.

BRIEF DESCRIPTION OF THE INVENTION

An object of the present invention is to create a more flexible information storage system than what is disclosed in said US patent 5813008. The object of the invention is achieved by the methods and equipment which are characterized by what is stated in the independent claims. The preferred embodiments of the invention are disclosed in the dependent claims.

The invention is based on the idea of organizing information items as views which are technically implemented as information tuples. In the con- text of the present invention, an information item means a well-defined quantity of information that can be addressed by means of an address or label. By way of example, an information item may be still or moving image (photograph, drawing, video clip, or the like), a music or sound file, an electronic document, or the like. As used in the present context, a view to an information item means that information item as personalized by a specific user (the owner of the view). A view specified by a user comprises a common portion and a personalization by that user. For example, if the information item is a photograph, the original photograph taken by user A may constitute the common portion, while another user B may specify that his view of that photograph is a cropped version with red eyes removed. In this case, the view of user B comprises the common portion made by user A and the personal edits made by user B. The technology may be used in cascade, ie, yet another user C may use the view of user B (including the common portion made by A and the edits made by user B) as a basis for his personal view which a further personalized view of the same photograph. Note that the users A through C may also refer to the same person, that is, one person may create different views to the same underlying photograph.

An information tuple means a set of fields which are treated as a whole. In other words, elements of an information tuple are not generated, moved or deleted individually. Information tuples can be implemented as data records, linked lists or any by means of any available technology.

The different views of an information item constitute a family which is preferably organized as a tree-form data structure. The root of the tree is called a first-order information tuple, and the child nodes are higher-order information tuples. The first-order information tuple indicates what is called a common portion of an information item. In other words, the first-order information tuple may actually store the common portion or only a reference to it.

The difference between a user-specific view and the preceding higher-order view is stored in the form of metadata in the information tuple that indicates that view. For example, if the first-order information item is an original photograph and a second-order view is an edited version of that photograph, the rules for repeating the edits may be stored in a metadata field of the second-order information tuple. In the context of digital images, reference 1 defines metadata as

"additional data linked with the image data beyond the pixels which define the image". This definition is applicable to other information types, such as music files, if we merely replace "image" with the information type in question.

In addition to personal preferences and/or edits, the views may be hardware-dependent, and they can also be generated automatically. For instance, the common portion of the information item may be a high-resolution photograph or a piece of music, and the user-specific views may be low- resolution or packed versions for hand-held terminals.

Whenever a user wishes to use an information item, he/she is provided with a reference to that information item. Users are authenticated and only authenticated users are provided with references to the information tuples. The users may be authenticated by means of an authentication system dedicated to the information storage system according to the invention, or the information storage system may rely on external authentication, such as the authentication performed by a mobile communication system or a mobile Internet system.

There is a reference-tracking system keeping track of references to an information tuple. Whenever a new reference is created or an existing one is deleted, the reference-tracking system increments or decrements, respectively, the reference field of that information tuple. Normally, the reference-tracking system deletes an information tuple its reference field becomes zero. This means that there are no references to that information item. In other words, nobody needs it anymore.

However, the reference-tracking system is actually more complex in that it is also capable of generating and tracking external links to an informa- tion tuple, and it defers deleting an information tuple if its reference field indicates zero but there are one or more external links to that information tuple exist.

The difference between a reference and an external link is as follows. As used herein, a reference is an electronic, or online, reference that is in complete control of the reference-tracking system. An external link is best illustrated by way of an example. When a hardcopy (a paper image) is printed of an electronic image, that hardcopy may include a printed reference to the electronic image. Within the context of this invention, such printed references, or any references which cannot be fully controlled by the reference-tracking sys- tem, are called external links. Since the external link only exists on paper, the reference-tracking system has no way of knowing whether the photograph with the external link has been stored or thrown away.

To further clarify the distinction between the references and external links, the prefix 'online' may be used to denote references which are main- tained by the reference-tracking system. According to the invention, the reference-tracking system does not delete an information tuple with zero online ref- erences, at least not immediately, if an external link to that information tuple exists. For example, the reference-tracking system may keep such an information for a predetermined time, after which the reference-tracking system may either delete the information tuple, or it may try to contact the user that re- quested the generation of the external link.

An advantage of the external links and the deferred deletion of non- referenced information tuples is that the system keeps track of generated hardcopies and can generate similar hardcopies, at least for a predetermined time, even if no online references exist.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following the invention will be described in greater detail by means of preferred embodiments with reference to the attached drawings, in which

Figure 1 illustrates the concept of views; Figure 2 illustrates an exemplary data structure for implementing the invention;

Figure 3 shows a block diagram of an embodiment of the invention and a network arrangement in which the invention can be used;

Figure 4 illustrates the concept of folders, access rights and refer- ences; and

Figure 5 illustrates an embodiment for automatic versioning.

DETAILED DESCRIPTION OF THE INVENTION

Figure 1 illustrates the concept of views by means of one concrete but non-exhaustive example. Reference numeral 110 denotes a digital photo- graph of a man and woman. A problem with the photograph is that the layout is poor because there is a dead tree sticking out of the man's head. Accordingly, image 120 presents a modified version (view) of the root-level photograph. In this example, the set of modifications comprises cropping the image as shown by outline 121. Reference numeral 122 denotes the cropped-out portion. An- other modification concerns the area 123 above the man's head. In the area 123, the tree has been retouched away, possibly by cloning similar image matter from an area above the woman's head.

References 130 and 135 are third-order images. In this example, image 130 is further cropped version of the man's head as edited in image 120. Image 135 is further cropped version of the woman's head in image 120. (For example, such cropped versions may serve as passport images.) Reference sign 121' denotes the outline of the referenced image 121.

Figure 1 shows several views. In this example, each version of an image is a view. Each view comprises a common portion and a set of unique portions. In the root-level image 110, the unique portions may constitute an empty set, which means that the view is the same as the common portion. Another reason for having an empty unique portion is a case in which an image should be associated with multiple categories. For example, image 120 could belong to a category of "family", "holiday" or "portrait". Such a multiple classifi- cation can be implemented by physically storing the image once, under one category, and arranging references from the other categories to the physically stored image. The references from the other categories need no modifications, and their unique portions are empty.

Figure 2 illustrates an exemplary data structure for implementing the invention. Reference numeral 200 denotes a first-order information tuple that stores the common portion, that is, the root-level information item that serves as a basis for all customized views. In this example, the first-order information tuple 200 contains three fields, namely a metadata field 201 , a reference count field 202 and a content field 203. The content field 203 stores or indicates the common portion. In other words, the content field 203 may actually store the common portion or only its address or locator. If the system of Figure 2 is used to store the family of images shown in Figure 1 , the content field 203 of the first-order information tuple 200 stores or indicates the original image 110. The reference count field 202 indicates the number of references to the information tuple 200. The metadata field 201 stores or indicates data relating to the information item, such as its owner, its creation date, etc. The well-known EXIF standard (Exchangeable Image File format) is a prime example of a metadata format that is particularly suitable for storing metadata relating to images. A reference is also made to "DIG35 Specification" by Digital Imaging Group, inc., see www.digitalimaging.org.

While each metadata field 201 , 211 , 216, etc., are shown as a single field, it should be understood that each metadata field may comprise a plurality of subfields or another data structure, such as a tree structure, for storing a large number of data items in an organized manner. Examples of metadata fields in the context of image data are disclosed in reference 1.

Reference numerals 210 and 215 denote two second-order informa- tion tuples that store two customized views of the root-level information item 200. A reference count field 212 indicates the number of references to the information tuple 210. A reference 213 contains a reference to the common portion of the view in question, that is, a reference to the first-order information tuple 200 (basically, to its content field 203). A metadata field 211 indicates the unique portion of the view stored in the information tuple 210. In other words, the metadata field 211 indicates the differences, if any, between the information tuple 210 and the common portion 203 stored in the referenced information tuple. If the system of Figure 2 is used to store the family of images shown in Figure 1 , the metadata field 213 of the second-order information tuple 210 stores or indicates the fact that the second-order image 120 is a cropped and retouched version of the original image 110.

The second second-order information tuple 215 has no corresponding image in Figure 1 , but an illustrative example may be a case in which the information tuple 210 is stored in category "portraits" and information tuple 210 is stored in category "holidays".

Reference numerals 220 and 225 denote two third-order information tuples that store two further customized views of the second-order information item 210. The portraits 130 and 135 shown in Figure 1 serve as illustrative ex- amples.

Figure 2 also shows two users 21 , 22, and a number of references 204, 214, ... , to the information tuples. Logically, each reference indicates that a given user reserves the right to use a given view (information tuple). Technically, a reference may be implemented as a stored association of a user identi- fier and an information tuple. The users do not manipulate the information tuples directly but only via a reference-tracking system that increments or decrements the reference fields of the information tuples in a synchronized manner. For example, as soon as a user 21 stores the original information tuple 200 (such as an original image), the reference-tracking system creates a refer- ence 204 which is an association of the user 21 and the information tuple 200. The reference count field 202 of the information tuple 200 is set to one. Each time a new reference to the information tuple 200 is created, the reference count field 202 is incremented by one. When the user 21 later wishes to delete the information tuple 200, the reference 204 is deleted and the reference count field 202 is decremented by one. If the reference count field 202 becomes zero, this means that there are no references to the information tuple 200, and it can be deleted. But if in the meantime other users have created references to the information tuple 200, it cannot be deleted even if user 21 no longer wishes to store it.

In order to further illustrate the concept of references, Figure 2 shows a third user 24 who has not created any references for himself. Assuming that user 24 has a read privilege to the original information tuple 200, he may see it as long as it is available, as indicated by the dashed line 241 from user 24. But since user 24 has not created a reference to the information tuple 200, the ability of user 24 to see that information tuple ceases as soon as last references to the information tuple 200 is deleted. User 22 has created a reference 230 to the information tuple 220 in order to ensure that the information tuple 220 is available to the user 22 even if the user 21 no longer wishes to keep it.

The reference-tracking system according to the invention is also ca- pable of storing offline or external references. The references discussed so far are internal or online references in the sense that the reference-tracking system has complete control over the references which are stored electronically in its database. But sometimes it is convenient to support external or offline references that are not controlled by the reference-tracking system. Such external references may be hardcopy (printed) references, or they may be references in a data processing system (eg a palmtop computer) that is not operationally coupled to the reference-tracking system according to the system. Reference numeral 25 denotes an example of an external reference. For example, when a photograph printed, the backside of the photograph may include the network address of the electronic image. Such a printed reference is an example of an external references. After the photograph is printed, the reference-tracking system has no control of such external references. For example, the photograph may be lost or thrown away in which case the external reference ceases to exist. But in some cases a user may wish to obtain another printed photo- graph, in which case the external reference helps to locate the information tuple indicating the electronic image.

Accordingly, when an external reference 25 is created, the reference-tracking system also creates a link 251 to the external reference 25. The link 251 is a piece of online information indicating that the external reference 25 was created. The reference-tracking system should also have a mechanism or logic to delete links 251 that are no longer used. In one embodiment, the links 251 have a creation date, and links that are not used for a predetermined time are deleted. The duration of the predetermined time depends on typical usage. For photographs, a suitable time may be one or a few years. Instead of such a predetermined time, or in addition to it, the reference-tracking system may attempt to consult the user who caused the creation of the link or the user who owns the information tuple referenced by the link.

Note that the link 251 is also counted as a reference. In the example shown in Figure 2, the reference count field 202 of the information tuple 200 indicates a value of seven, because there are six internal references plus one external one.

When an external reference is created, it is preferably printed in a machine-readable form. For instance, the external reference can be printed on the back side or in the margin of a photograph. The machine-readable external reference can then be scanned electronically. A preferred technique for scan- ning a printed external reference is to use a mobile terminal that comprises a camera and a scanning program. When the terminal user wishes to download an electronic version of an image, the external reference can be photographed and scanned, after which the scanned external reference is sent to a server that returns the requested image. Figure 3 shows a block diagram of an embodiment of the invention and a network arrangement in which the invention can be used. This embodiment is based on a client-server architecture, shown as C and S. The client side comprises a client terminal CT for accessing a communication server CS via a data network DN. For example, the data network DN may be an Internet Protocol (IP) network, such as the Internet or its closed subnetworks, commonly called intranets or extranets. The particulars of the data network are not essential to the present invention. In case of mobile users, there may be an access network, such as a mobile communication network, between the client terminal CT and the data network DN. In this example, there is an access net- work AN, such as a mobile communication network or a mobile Internet, connected to the data network DN. Alternatively, the communication server CS can have separate interfaces for the data network DN and the access network AN. The communication server CS employs or relies on an authentication mechanism AU to authenticate the client. The authentication mechanism AU may be built into the communication server CS, or it may be a separate authentication server. Alternatively, the authentication mechanism AU may be a mechanism that relies on an authentication performed by the access network AN. In this example, the access network AN (show as a mobile communication network) comprises an authentication centre AuC, and the authentication mechanism AU of the server arrangement may consult the authentication cen- tre AuC of the access network.

The data structures shown in Figure 2 are stored in a database system DB. The internal structure of the database system DB is not essential to the present invention. The database system may be comprise one or more individual databases and it may be implemented in a centralized or distributed manner, as is well known to skilled readers.

There is an access control mechanism AC to grant selective access to the database system DB. An example of an access control mechanism operates as follows. Today, many users are familiar with a folder-like data structure and user groups, and such concepts work well in the context of the pre- sent invention. For example, users may organize their data, such as images, in folders. Each user has a set of user groups, such as "family", "colleagues", "golf-club-members", etc. The owner of a folder assigns a specific access right to each folder. For example, members of the "colleagues" group may have a read/write access to a "work" folder, whereas members of the "golf-club- members" group may have only read access to a "golf-images" folder.

According to the invention, all accesses (at least all accesses with a write privilege) are processed by the reference tracking system RT that keeps track of the references, as described above in connection with Figure 2. The purpose of the reference tracking system RT is to ensure that the set of views of an information item are stored in a systematic manner. That is, there is a information tuple for each view, the common portion is stored only once, and the inter-related references are tracked systematically.

In order to ensure that the references are information tuples are created and deleted in a synchronized manner, even in the case of system malfunction or power shortages, the reference tracking system RT should employ transaction processing with commit and rollback procedures, as is well known to those skilled in the art.

The concepts of folders, user groups and privileges are well known to those skilled in the art. However, a preferred embodiment of the invention proposes a novel type of user privilege, namely the right to create references. A benefit of such a privilege is as follows. Assume that a user publishes an image in a folder which has a "read" access to all users (or a user group of "guests"). A visiting user may become interested in the image. For example, he may start a discussion on a user group, and that discussion includes a reference to that image. The visiting user may create a reference to the image to ensure that the image will remain in place while the discussion is active. If the owner of the image wishes to delete or alter the image, he may receive a notification that the image is referenced by a visiting user.

In order to support external references, such as hardcopy images, the system as shown in Figure 3 preferably contains hardcopy generation equipment HG and, preferably, an image-processing application IA that are controlled by a terminal TE. The terminal TE may or may not be the same terminal as the client terminal CT. For example, if the client terminal CT is a general-purpose computer with a suitable printer and, optionally, image-editing software, the elements TE, IA and HG may be included in the client terminal CT. Alternatively, the elements TE, IA and HG may be installed in a shop or outlet having a photograph-quality printer.

The hardcopy generation equipment HG is preferably such that each printed image is provided with an external reference in a machine- readable form. As used herein, a machine-readable form means that reason- able steps are taken to ensure that the external reference can be scanned automatically, given the data-processing capabilities of a typical multimedia terminal. For example, a barcode is certainly machine-readable, as is a high- contrast (alpha)numerical reference. But a reference printed over a random background, such as the date/time stamp created by many cameras, is not readable with today's multimedia terminals.

A residual problem to be solved by the invention is how the system of Figures 2 and 3 knows how a customized view differs from the root-level image or an intermediate image. To phrase this question more generally: how does the system know how a view of order n differs from the referenced view of order n-1? There are at least three ways to solve this residual problem, two of which are based on the fact that many image-processing applications keep track of user actions in an action log (which is useful for undo and redo operations). If the image-processing application IA is closely coupled to the server and database system DB, the image-processing application IA may simply store the user actions in the unique portion of each view. For instance, the metadata field 216 of the information tuple 215 in Figure 2 would comprise all the necessary user actions to generate the view 215 from the root-level image indicated by the content field 203 of the first-order information tuple 200. Alternatively, if the image-processing application IA is executed in the client terminal CT, the image-processing application IA may be customized to export the series of user actions to the server. As a third option, if the client terminal CT sends a modified view to be stored, the server may perform an image comparison between the user-modified view and the referenced image, and only store the changed areas in the unique portion of the view to be stored. For example, if a user is about to store the image 120 shown in Figure 1 , the server may perform an image comparison between images 120 and 110. The comparison would show that area 122 has been cropped and area 123 has been edited.

Figure 4 further illustrates the concept of folders, access rights and references. Figure 4 shows the three users 21 , 22 and 24, and the information tuples (eg images) 200, 210, 215, 220 and 225, which were shown in Figure 2. In the example shown in Figure 2, the images are stored in three folder as follows. The first-order information tuple 200 that indicates the root-level image is stored in a first folder 41 of user 21. Two further views 210 and 220 are also stored in the same folder. (In connection with this example, the terms 'view' and information tuple are used interchangeably because each information tuple stores one view of the root-level image 200.) User 21 has stored view 215 in his second folder 42. User 22 has stored view 225 in his folder 43. Figure 4 has three types of arrows, each representing a different relationship, as shown in the bottom right-hand corner of Figure 4. Each thick arrow denotes an "owns" relationship, and user 21 owns the views 200, 210, 220 and 215 that are in his two folders 41 and 42. User 22 owns the view 225 that is stored in his folder 43. Each thin continuous line denotes a "references" relationship (which is implicit in the "owns" relationship). User 22 has created a reference to view 215, which means that view 215 remains in place even if its owner (user 21 ) no longer wishes to keep it. Each thin dashed lines denotes a "sees" relationship (which is implicit in the two above-mentioned relationships). Users 21 and 22 have at least a read access to all folders, which means that they can at least see all views (images) stored in these folders.

User 24 has a read-only access to folders 41 and 43, which means that he can see views 200, 210, 220 and 225 but not the view 215 that is stored in folder 42. Figure 4 also shows a fourth user 46 who cannot see any views, either because he failed authentication or does not belong to any user group having at least a read access to the folders 41 to 43.

Note that the combination of folders and user groups is a convenient way to organize accesses, but it is not the only way. Instead of folders, or in addition to them, access rights can be granted on a view-by-view basis or some other suitable technique. For example, the first or last character of a view's name may indicate if and how the view is protected. Instead of user groups, or in addition to them, accesses can be granted to individual users, but it is self-evident that the combination of folders and user groups is more con- venient.

Figure 5 illustrates an embodiment for automatic creation of versions, such as different image resolutions. In the embodiments described so far, the assumption was that a users create different image versions. But sometimes the versioning is a rather mechanistic process that can be largely automated. This is particularly the case when the reason for the versioning is different terminal capabilities. For example, printers, computer displays and hand-held terminals support vastly different resolutions. A similar situation exists in storage of music files; hi-fi users prefer an unpacked version of a piece of music while mobile users prefer a densely-packed version. Figure 5 shows three different terminals, namely a powerful image- processing computer 51 , a laptop computer 52 and a hand-held terminal 53, such as an advanced mobile telephone. In this example, the hand-held terminal 53 accesses the server S via an access network AN, which typically has a lower bandwidth than the data network DN (many intervening network ele- ments have been omitted for clarity).

In the embodiment shown in Figure 5, the server arrangement S comprises a gateway section 54 and an automatic converter section 55. The gateway section 54 is preferably connected to an equipment register ER and/or a subscriber register SR. These registers may be operated by the op- erator of the server arrangement S or by the operator of one of the networks DN, AN. In this embodiment, the database system DB is divided into multiple sections, of which three sections 57 to 59 are shown. These sections are called high-, medium- and low-resolution sections, respectively. Note that the number of sections, three, is merely an example. The idea is that high- resolution images (or music files, etc.) are stored in the topmost section 57, and the automatic converter 55 performs automatic down-conversions to dif- ferent resolutions, as shown by line 56. The different resolutions are stored in the remaining sections 58 and 59. For example, the different sections 57 to 59 may be implemented as folders or file prefixes or suffixes.

The gateway section 54 operates as follows. When a user of one of the terminals 51 to 53 wishes to access a file stored in the database system DB, the gateway section 54 determines an optimal resolution and modifies the access request accordingly. For example, a user of mobile terminal 53 may use a network address that points to the high-resolution section 57 of the database system DB, but the gateway section 54 determines that a more appro- priate version for hand-held terminals is presumably stored in the low- resolution section 59. The gateway section 54 may make this determination based on the protocol used by the terminal or one or both of the registers ER, SR. As a further alternative, the gateway section may consult the terminal user. The expression "presumably stored in the low-resolution section" means, for example, that the medium- and low-resolution versions in the respective sections 58, 59 may not be stored permanently but temporarily, in a cache- type storage. In other words, when a file of a given resolution is requested, the file with the requested resolution is created and stored in the respective section 58, 59, optionally with a time stamp. Each time the image is accessed, its time stamp is renewed. When the time stamp exceeds a predetermined age, or when the corresponding section 58, 59 becomes full, the medium- or low- resolution file is deleted. The data structure shown in Figure 2 is also suitable for storing such automatic versions. The time stamps can be stored in the metadata fields 211 , 216, etc. Another use for the automatic generation of images in multiple resolutions is that a graphical user interface can use the low-resolution images in section 59 as shortcuts or "thumbnail images". When the terminal user clicks on a low-resolution image, he is shown a medium- or high-resolution image, depending on the terminal's capabilities. A comparative example is the case of music files. The high- resolution section 57 may comprise unpacked music files that are sold for a premium price. The medium-resolution section 58 may comprise packed versions for portable terminals at a lower price. The low-resolution section 59 may comprise even more densely packed music files and/or descriptive samples of music files that are distributed free of charge for evaluation. Further preferred embodiments

The invention can be used for many different purposes and in a wide variety of environments. According to one preferred embodiment, a system (storage server with its associated databases) substantially as described above is operationally connected to a terminal's multimedia message creation system. In one illustrative implementation, a user interface for creating multimedia messages comprises a link to the data structure substantially as shown in Figure 2. In response to clicking the link, the user interface presents the user with a graphical view to the data structure, such that each information item is shown as a thumbnail image. Selecting an image may result in the user seeing a higher-resolution image and/or metadata relating to the image. Further, the user may be presented with a form for searching suitable images (or other media files) based on keywords that are stored in the metadata fields.

According to another preferred embodiment, the system comprises means for automatically providing a user with a summary of all metadata fields or their selected subfields. For example, if the user selects metadata subfields "location" and "keywords", the system may present the user with an exportable/importable file that lists the location and keywords for each image in the directories selected by the user. According to yet another preferred embodiment, the system comprises a logic for assembling statistics indicating usage of the information items. For example, the statistics may include the number (or frequency) of accesses or a user rating (such as a one to five-star rating system based on user votes).

To keep the description compact, the invention and its embodiments have been described mainly in connection with images, such as photographs or video clips. But the invention is applicable to many other types of information items. A good example is music files which can be stored in varying packing ratios. Another example is database queries which are customized or fur- ther refined to different users. Yet another example is document files in varying versions or with different comments. Thus the invention and its embodiments are not limited to the examples described above but may vary within the scope of the claims.

Claims

1. An arrangement for storing, in a data network operated by a network operator, a plurality of information items and one or more views of each information item, wherein each view is based on a common portion and com- prises one or more unique portions; the arrangement comprising: a database system (DB) for storing, for each information item, a first-order information tuple (200) and one or more n^th order information tuples (210, 215, 220, 225), wherein n is a natural number higher than one, wherein the first-order information tuple comprises:

- a metadata (201) field for describing the information tuple;

- a content field (203) for indicating said common portion; and each n^th order information tuple comprises:

- a metadata field (211 , 216, 221 , 226) for indicating said one or more unique portions;

- a reference field (213, 218, 223, 228) for indicating a reference to an information tuple of order n-1 ; the arrangement further comprising: access control means (AU, AC) for providing only authenticated us- ers (21 - 24) with references (204, 214, 219, 224, 229, 230) to said information tuples; a reference-tracking system (RT) for keeping track of references to information tuples, wherein the reference-tracking system (RT) is operable to delete an information tuple to which there are no references; wherein the reference-tracking system (RT) is further operable to:

- generate and track external links (251) to an information tuple; and

- defer deleting an information tuple to which there are no references if one or more external links to that information tuple exist.

2. An arrangement according to claim 1 , wherein the first-order in- formation tuple comprises a reference count field (202) for indicating a number of references to the first-order information tuple; and each n^th order information tuple comprises a reference count field (212, 217, 222, 227) for indicating a number of references to the n^th order information tuple in question; and a reference-tracking system (RT) is operable to increment or dec- rement the reference field of an information tuple, in response to creation or deletion, respectively, of a reference to the information tuple in question.

3. An arrangement according to claim 1 , wherein the reference- tracking system (RT) is operable to defer deleting an information tuple for a predetermined lifetime of that information tuple.

4. An arrangement according to claim 1 , wherein the reference- tracking system (RT) is operable to consult a user before deleting the information tuple to which there are no references.

5. An arrangement according to claim 1 , further comprising means (54 - 59) for automatically generating and storing multiple different versions of an information item.

6. An arrangement according to claim 1 , wherein the information items comprise images.

7. An arrangement according to claim 6 wherein the metadata field (211 , 216, 221 , 226) of at least one n^th order information tuple indicates said one or more unique portions as one or more user actions of an image- processing application.

8. An arrangement according to claim 5 wherein the metadata field (211 , 216, 221 , 226) of at least one n^th order information tuple indicate said one or more unique portions as a result of an image-element comparison (122, 123).

9. An arrangement according to claim 1 , further comprising an authentication system (AU) for authenticating users (21 - 24, 46).

10. An arrangement according to claim 1 , wherein the access control means are operable to cooperate with an external authentication system (AC).

11. An arrangement according to claim 1 , further comprising hard- copy generating means (HG) for generating a hardcopy of a requested view.

12. An arrangement according to claim 10, wherein the hardcopy generating means are operable to print an external reference (25) in a machine-readable form.