Re: [new use case suggestion] Use Case - Digital imaging lifecycle

Dear all,

it make sense to me to cover all the three main media categories (video, 
still images and audio) as a hole or as three separated parts.

However, the intention of my example was not so ambitious, it was just 
related to what in DIG35 (cited in the PhotoUC) is named "History Metadata":

>From Section 3.2.4 in DIG35 
( :

"For example, history may include certain processing steps that have been 
applied to an image. Another example of a history would be the image 
creation events including digital capture, exposure of negative or reversal 
films, creation of prints, transmissive scans of negatives or positive film, 
or reflective scans of prints. All of this metadata is important for some 
applications. To permit flexibility in construction of the image history 
metadata, two alternate representations of the history are permitted"

I think that EXIF and other formats mix this concept with the metadata of 
the resource (e.g. the Exposure Time field in EXIF) but others like DIG35 or 
MXF and AAF (Part 15 of talks about 
Physical Essence) make a clear differentiation.

What about a "History Metadata" Use Case?

Best regards,


----- Original Message ----- 
From: <>
To: "Víctor Rodríguez Doncel" <>
Cc: "Felix Sasaki" <>; "Pierre-Antoine Champin" 
<>; "Rubén Tous" <>; 
Sent: Tuesday, November 04, 2008 9:58 AM
Subject: Re: [new use case suggestion] Use Case - Digital imaging lifecycle

> Dear all,
> How about this solution: we could group a number of use cases under the 
> "media"
> category, as we already have an "audio" use case, and take into account in 
> the
> ontology 1.0 only the requirements that overlap with others? The 
> description of
> the use case would show what other aspects still need to be taken into
> consideration when aiming for still images description compatibility.
> Best,
> Veronique
> Quoting Víctor Rodríguez Doncel <>:
>> Hello all,
>> I think it should be distinguished between the user roles regarding the
>> resource, and the user roles regarding the represented object.
>> Thus, the three kind of applications or roles defined by the
>> metadataworkinggroup (creator/changer/consumer) operate on the resource
>> but may not match logically the role regarding the represented object.
>> For example, the word "creator" is somewhat ambiguous because it may
>> refer to the role which creates materially the resource, or to the
>> actual artist which conceives an idea. Both "creators" do not
>> necessarily match. Have you thought about it?
>> Regards,
>> Víctor Rodríguez Doncel
>> Felix Sasaki escribió:
>> >
>> > Pierre-Antoine Champin ã.ã,"はæ>¸ãã¾ã-ãY:
>> >> Felix Sasaki a écrit :
>> >>>
>> >>> Hello Ruben, all,
>> >>>
>> >>> sorry for the late reply. Reading your proposal I think it is
>> >>> interesting for the photo use case. However I remember that we
>> >>> discussed at the f2f meeting about the focus of the Working Group,
>> >>> and most of the people want it to be video, with the possibility to
>> >>> take other use cases into account if their requirements overlap more
>> >>> or less with video.I am a bit worried that your description is too
>> >>> far away from that use case. What do others think?
>> >>
>> >>
>> >> Although the examples given by Rubén are quite specific to still
>> >> images, it seems to me that a similar kind of concern exist for
>> >> video: video can be digitalized from analog media, captured by
>> >> digital devices or generated; they can be altered in several ways
>> >> (re-encoding, subtitling, montage...).
>> >
>> > Good point. I think an implementation of this is to  separate actors
>> > or roles like creator, changer and consumer. This is what the metadata
>> > working group deliverable does, see section 2 of
>> >
>> > However what you are mentioning and what Ruben describes sounds to me
>> > rather like a requirement than a use case, that is the requirement to
>> > take such roles into account for relating various metadata
>> > vocabularies. What do you think?
>> >
>> > Felix
>> >
>> >
>> >

Received on Tuesday, 4 November 2008 09:15:02 UTC