Type derivation
New types can be derived from existing types. This mechanism allows to reuse the capabilities (fields and methods) of the previous types while adding new capabilities to the new types. FIG. 13 shows an example where a new type <Photo> 1310 is derived from an existing type <Image> 1300. The existing type has an Object_ID 1320 equal to 1005 and the new type has an Object_ID 1330 equal to 1017, both above 1000 because they are types for user objects. The Ancestor_ID of the <Image> type 1340 is equal to 1000, which means that it is a “basic” user type (derived from the commonest <Object> type), whereas the Ancestor_ID of the <Photo> type 1350 is equal to 1005, which states the type derivation.
In Practice, this example of derivation is useful since a photo is actually an image, i.e. an array of colored pixels, hence the data and metadata fields for representing an image are suitable for representing a photo. But a photo can define new data or metadata fields, such as color specs for accurate color representation or camera attributes (brand and model, objective aperture, shutter speed, focal distance, sensibility, etc.) that may not be intrinsic to other images, for example, drawings and illustrations. Furthermore, the software tools available for image manipulation can also be applied to photos, although the reverse situation should not be appropriate.
FIG. 14 is a more complex example of type derivation. The type <Sequence> 1400 describes objects composed of a sequence of images (i.e., an animation), being those images registered as a {list of images} 1405. This list can be implemented as an array of objects of type <Image> 1300, which is represented by the double arrow 1450, where the label [1..n] indicates that there must be at least one image in the list.
The type <Portrait> 1410 describes objects that correspond to photos of people intended for formal identification, such as passport photos. Since a portrait is indeed a photo, it is derived from the type <Photo> 1310, though a portrait must include an Identity field 1415 that certifies that the person shown in the photo is actually the one that the name and description of the portrait says he or she is. This information may be an object of type <Certificate> 1420, that must be emitted by an authorized organization (government offices). The mandatory inclusion of such certificate is expressed by the plain arrow 1470, and the inventive system will not permit the users to change associated certificates (or other security-related information) in any manner.
The type <Avatar> 1430 describes objects that iconographically represent the identity of a person, by means of one formal image and possibly another informal image. Whether there are one or two images, it can be managed as a sequence. For this reason, the type <Avatar> is derived from the type <Sequence>. However, there are some constraints on the images that can be included in the {list of images} 1435 of the type <Avatar>, which is basically a data field inherited from its ancestor type (thus the field is written in gray). These constraints are graphically expressed as the inclusion of zero to one generic (informal) image, with the dashed arrow with label [0..1] 1460, and the inclusion of strictly one formal image with the dashed arrow with label [1] 1465, being this formal image an object of type <Portrait>. In this manner, a user that receives an avatar from another user (within an e-mail, for example) may see the informal image first, but he or she always will be able to disclose the formal image to identify confidently the person who sent the avatar.
As an example on how the user could manage such information, let us add another drawing (not present in the US Patent) for illustrating how to switch the two images:
When moving the cursor over the first image of the avatar, some kind of mark must indicate that there are other images available (e.g., a circle with an N, for Next). Clicking once on that symbol may show the next image of the sequence. Since the second image has an associated certificate, another mark (e.g., a circle with a C) should allow the user to read the certificate details.
A final consideration is that the specific constraints for the list of images within an object of type <Avatar> must be verified by the corresponding setField() method of this type, which overrides the existing setField() method for the type <Sequence>. Nevertheless, the overriding method may call the existing method to reuse the basic code to check the validity of the included images. For this purpose, any object of type <Portrait> must be considered as an object of type <Image>, in order to allow to include a portrait in a sequence of images. To this aim, the inventive system generalizes the type of an object to any of its ancestor types.