Defining Metadata Fields

Internationalization is disregarded in this drafting phase

This section describes an intermediate framework for describing metadata fields.

It is to be used to create a draft for the XESAM metadata fields. When the actual field definitions are taking shape we will evaluate the description framework and change it if it was found insufficient or cumbersome.

The final metadata descriptions are likely to be more rich than what is described in this document, but this should be enough to get us started.

Metadata fields are described like this

[Audio:Composer]
Parent=DC:Creator
Type=list(string)
Name=Composer
Description=Composer of the track

Formal name: The part in square brackets is called the the formal name of the field. The formal name must be unique among all known formal field names and is not meant for display. The formal name ROOT is reserved - see the Parent-definition below for an explanation.

Parent: The formal name of the parent field (if any). Searching for a value in a field will also yield hits on matches in any child fields. Fields without any parent should specify the reserved name ROOT as their parent.

Type: This property can be one of string, integer, float, date, and boolean. These are called simple types. To specify a multi valued field you write list(simple_type). Like list(string) in the example above. To specify that a field only can take values in a certain range, use range(simple_type,simple_type,...). Fx

range(1-10)
range("foo","bar","baz")
range(0.0-1.0)

The range selector takes a either a comma separated list of values or a from-to pair. The first example above specifies integer values in a range from 1 to 10, 1 and 10 inclusive. The second example specifies that the field takes values in the set of strings "foo", "bar", and "baz". The third and last example define that the field take floating point values in the range from 0 to 1 (including 0.0 and 1.0).

Name: This is the display name for the metadata field. Unlike the formal field name this is not required to be unique although it will be a good idea in many cases.

Description: The string giving a short description of the field suited for display

Ontology Guidelines

Here follows some basic guidelines that should be kept in mind when designing the xesam ontology.

KIS: Keep it Simple. As much as it would cool to have a really detailed ontology catching even the subtlest distinctions, remember that XESAM aims to be

easy to adopt by actual implementors
easy to use by end-user application developers
easy to maintain
have minimal, if any, need for 3rd party depencies to parse or maintain the ontology

On top of that it is a general nice trait if developers can remember the most common field names after using them a few times. It should not be required that you read documentation each time you interface with a xesam service.

Inheritance: Only create child fields if they add additional implications including but not limited to introducing ranges, controlled-vocabulary, or disambiguating a generic field (see fx. the keywords example in the paragraph below). Consider for instance content.genre field which describes the genre of of generic "content". This could be the genre of music, video, novels, etc. One might be tempted to create a child field audio.genre of content.genre since this might be natural for a music player application. This doesn't bring any huge benefits to the music player since it can still easily query content.genre and restrict the search to objects of type audio. Creating a child field of content.genre containing a controled vocabulary audio genre might make sense though.

Beware of Ambigous Fields: Some fields should actually be split in two or more fields even though they meaning appear well defined on first sight. A prime example is keywords. It would be tempting to define a single field item.keywords for keywords (also known as tags). This leads to trouble however. Some docuemnts contain embedded keywords that might have been put there by the author or some publisher to categorise the document. This shouldn't be intermixed with user defined keywords (also called tags) - some applications might want to list all user defined keywords and not inter mix these with some generic keywords describing a scientific publication lying on your hard drive.

Don't Describe the Entire World: As it is the goal of this spec to allow 3rd parties to install custom ontologies the basic xesam ontology should not cover everything that you could possibly dream of. Special applications will have to install their own field definitions.

Draft

The current ontology draft can be seen at XesamOntologyDraft.

Related pages

Resources

Meetings

Defining Metadata Fields

Ontology Guidelines

Draft