To be revised

Summary: Accessing media collections of different cultural heritage institutions (libraries, museums, archives, etc.) on the Web.

Related requirements:

Description / Example:

The collections of cultural heritage institutions (libraries, museums, archives, etc.) are increasingly digitised and made available on the Web. These collections range from text to image, video and audio (music and radio collections, forcollections example). A comprehensive, professionally created documentation is usually available, however, often using domain specific or even proprietary metadata models. This hinders accessing and linking these collectionscollections. The media types that are archived in ana cultural heritage perspective range from image to homogeneous or centralized way and linking them across collections.

For example, Jane is a TV journalist searching for material about some event in contemporary history. She is interested in televisionmovie clips and radio broadcasts from this event, along with photos and newspaper articles. All these resources come from different collections,languages. She and some are in different languages. A homogeneous way of accessing them across the Web would improve her work. Web.

Summary: Accessing heterogeneous media objects metadata as the input to the creation of recommendations which is based on user preferences.

Related requirements:

Description / Example:

People nowadays are able to enjoy large number of programs from different content providers (broadcasting companies, Internet video website, etc.). To achieve better user experience, reduceuser history based recommendation is very promising. Recommendation the user's experienceto of being overloaded, and henceretain users by retain users, some systems provideof recommendations based on the user's history, ratings, or stateduser preferences. However, different content providers usually have their specific or proprietary metadata models, which is one of the key problems faced by recommendation service providers. A common ontology spanningacross different metadata sets can allow recommendation systems to return a better, larger, and more relevant selectionusers than when the metadata systems are unrelated. metadata.

Company A is an IPTV add-value service provider. One of their services is to recommend programs that users might like, based on their watching history or explicit rating of programs. In this system, users are able to watch regular TV programs with electronic program guide (EPG) format metadata, videos such as fromvideos YouTube, with website-specific metadata, etc. In order to perform uniform and effective recommendation in theuniformly absence of a common set of vocabularies, they would need to design own integrated media annotation model.

Use case summary: combining heterogeneous metadata from life logs, to allow searching personal life log information, potentially enriched with geolocation information.

Related requirements:

Description / Example:

With modern devices, aA person can capturecaptures his or her experience, including all sorts oftheir daily events, by creating images, audios and videos files, and publish them on the Web. These are called "Life Logs". These Life Logs contain various information such as time, location, creator's profile, relations between differenthuman people, and even emotion. If accessed via an ontology providing links between the different metadata usedthe to describe these various information, a user couldcan easily and efficiently search for his or herhis/her personal Life Log information, including emotional information ( this type of information can be described using a vocabulary like ), or geolocation information on the Web (which can be describedweb, using the specification). Other people's Life Logs contents could also be searched and accessed via this ontology.necessary.

Use case summary: Accessing metadata in heterogeneous formats for web developers

Related requirements:

Description / Example:

John is developing a JavaScript library for accessing metadata of media objects (e.g. video) in various formats. These objects are available within a database, such as that of a search engine indexing the internet or other web-accessible content (e.g. a corporate repository, library, etc.). His library can be used to make queries of the media objects like:

This use case is related to many other use cases. Nevertheless it is mentioned separately since, at the difference fromother requirements, its implementation requires only a small set of requirements. TheAlso, the difference from this use case is not to require or to thepropose developing a Cultural Heritage use case is that the formerontology can be is very strongly tied to the requirement of such a read-only client side API.language.

Use case summary: Adding or linking to external metadata by different users.

Related requirements:

Description / Example:

John wants to publish comments on the last movies he has seen on http://example.cheap-vod.com/ . For each movie, he uses the description metadata field to provide a personal summary of the movie (with incentive to see or avoid the movie according to his own opinions), and the ranking metadata. John is also not satisfied with the genre classification of the website, so he uses the genre metadata field to provide his appreciation of the genre with regard to a better scheme. He then publishes these metadata on his blog (may be in the form of a podcast), but only links to the videos themselves.

Jane, a friend of John's and another cheap-vod customer, can now configure her cheap-vod account or her browser, to have John's metadata added to or replacing the original metadata embedded in each file.

Now Jane wants to study more particularly the characters of the movie. For making this easier, she defines one custom metadata field for each of the main characters, and sets these fields to "yes" or "no" for each sequence, to indicate if they contain that character or not. For example:

In this context, the ontology would enhance the interoperability between different users.

Description: The API MUST provide methods for getting metadata out of media objects in different formats.

Rationale: This is a core requirements. Its implementation is necessary for nearly all use cases.

Target (API and / or ontology): API

Description: The API MUST provide methods for setting metadata in media objects in different formats.

Rationale: The implementation of this requirement is mainly necessary for use cases which involve change of media objects by users.

Target (API and / or ontology): API

Description: The API MUST provide a means to support structured metadata to media objects, like the name of the creator being structured in "first name" and "last name".

Rationale: There are existing, widely used formats like which are defined in a structured manner. To be able to support meta information for media objects, including such formats, the API needs to have a means to achieve this.

Target (API and / or ontology): API

Description: It MUST be possible to access user-defined metadata to media objects. "user-defined metadata" means metadata that is not defined in a standardized format, but which is being created entirely by the user.

Rationale: The ability to access user-defined metadata is necessary for the use case user generated metadata.

Target (API and / or ontology): API which needs to provide a method to add user-defined metadata, and the ontology which needs to provide an extensibility mechanism.

Description: the ontology MUST be available as a simple set of properties, to hide complexity for whose who do not need it.

Rationale: In use cases like access via web client to metadata in heterogeneous formats it is important to hide the potentially complex ontology from the web developer. This will foster ease of use and wide spread adoption.

Target (API and / or ontology): API and ontology

Description: The ontology MUST be provided not only in prose description but also as an internal or external format.

Rationale: to be able foster interoperability between applications, a common format for the ontology will be helpful. To avoid the need to process this format for all implementations, the specification(s) will provide separate slices of conformance, see Requirement r11: providing the ontology in slices of conformance.

Target (API and / or ontology): Mainly the ontology, but possibly also the API, if we require it to process this format.

Description: The ontology MUST provide several abstraction levels.

Rationale: Several metadata standards like or allow referring to multimedia objects on several abstraction levels, in order to separate e.g. a movie, a DVD which contains the movie and a specific copy of the DVD. Especially for collections of multimedia objects, knowledge about such abstraction levels is helpful, as a means for accessing the objects on each level.

Target (API and / or ontology): ontology and potentially API, if we want to provide access to metadata and multimedia objects on several abstraction levels.

Description: It MUST be possible to access collections of metadata.

Rationale: For processing collections of multimedia objects, access to collections of metadata referring potentially to more than one object is necessary. As an example for the need for this requirement and a related requirement see Requirement r07: Introducing several abstraction levels in the ontology.

Target (API and / or ontology): API and ontology

Description: Different roles in metadata processing MUST be taken into account.

Rationale: Metadata is being dealt with by for example producers of metadata (e.g. a video camera), changers (e.g. a person which modifies initially created metadata) and consumers (e.g. an application which processes metadata to make it accessible for search). If several pieces of metadata, created by machines or people in different roles, are in conflict (e.g. contradictory creation dates), a description of provenance related to roles can be useful for conflict resolution (e.g. "metadata produced by the changer has provenance over metadata produced by the creator").

Target (API and / or ontology): ontology

Description: It MUST be possible to relate metadata to fragments of media objects.

Rationale: Processes like search may be specific to fragments of media objects, e.g. a search for all kiss scenes in a movie. The implementation of this requirement provides the means to implement such processes.

Target (API and / or ontology): none of these

Description: The ontology MUST be provided in a prose description and MAY be provided in different serializations (RDF, XML). The yet to be produced general conformance description MUST require implementations to take the prose description into account. Additional conformance descriptions, being specific to a serialization, MAY be provided.

Rationale: Existing metadata formats use a wide range of serializations like RDF and XML. To foster a widespread adoption of the ontology, we do not want to be specific to one serialization, but rather state that following the prose description is sufficient for an implementation. If there is a interest in the Working Group to create one or more serializations, we may provide additional types of conformance for them.

Target (API and / or ontology): ontology

Description: It MUST be possible to take information from controlled vocabularies for certain properties into account.

Rationale: Media archives often make use of controlled vocabularies (e.g. classifications, thesauri, ontologies) for certain properties. Providing access to knowledge about which vocabulary is actually being in use for a media object, is an important requirement for such archives.

Target (API and / or ontology): ontology (for describing properties which need a slot for specifying a controlled vocabulary) and the API ( for getting information about which vocabulary is being used for a media object)

Description: It MUST be possible to provide different return types for the same property.

Rationale: Some properties are defined with the same name and functionality (e.g. conveying information about the creator of a media object), but use different value types (e.g. string versus URI). This raises the question whether the API should be specific to only one return type, or allow for undefined/unformatted return values forseveral the same property. ones.

Target: API