This document defines the Ontology for Media Resources 1.0. The term "Ontology" is used in its broadest possible definition: a core vocabulary. The intent of this vocabulary is to bridge the different descriptions of media resources, and provide a core set of descriptive properties. This document defines a core set of metadata properties for media resources, along with their mappings to elements from a set of existing metadata formats. Besides that, the document presents a Semantic Web compatible implementation of the abstract ontology using RDF/OWL. The document is mostly targeted towards media resources available on the Web, as opposed to media resources that are only accessible in local repositories.
This is the Proposed Recommendation Working Draft of the Ontology for Media Resources 1.0 specification.
It has been produced by the
Please send review comments about this Proposed Recommendation to the
public mailing list
The
For convenience, the differences between this document and the
This Proposed Recommendation version of the Ontology for Media Resources 1.0 incorporates requests for changes from comments sent during the first Candidate Recommendation period and changes following implementation experiences from the Working Group.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the
Last Modified: $Date: 2011-10-13 13:34:33 $
This
document
defines
ontology
that
consists
of
the
Ontology
for
Media
Resources
1.0.
In
this
document,
the
term
"ontology"
is
used
in
its
broadest
possible
definition:
a
core
vocabulary,
which
vocabulary.
The
Ontology
for
Media
Resources
1.0
is
both
a
common
core
vocabulary
(a
set
of
properties
to
describe
the
basic
metadata
needed
for
describing
entities,
resources
the
semantic
links
between
their
values
in
different
existing
vocabularies.
This
ontology
helps
the
programs
its
mapping
to
support
the
interoperability
among
the
various
kinds
a
set
of
metadata
formats
related
to
currently
describing
media
entities
resources
published
on
the
Web.
Status
of
this
Document
This
section
describes
the
status
of
this
document
at
Mappings
to
formats
for
media
resources
non
available
on
the
time
of
its
publication.
Other
documents
may
supersede
Web
have
not
been
taken
into
account
in
this
document.
A
list
version
of
current
W3C
publications
and
the
latest
revision
Ontology.
The
purpose
of
this
technical
report
can
be
found
in
the
W3C
technical
reports
index
at
http://www.w3.org/TR/.
This
mappings
is
the
First
Public
Working
Draft
to
provide
an
interoperable
set
of
metadata,
thereby
enabling
different
applications
to
share
and
reuse
these
metadata.
The
set
of
properties
of
the
Ontology
for
Media
Entity
Resources
1.0
specification.
It
has
been
produced
by
was
selected
with
respect
to
the
Media
Annotations
Working
Group
,
which
is
part
most
commonly
adopted
set
of
the
W3C
Video
on
the
Web
Activity
.
elements
from
metadata
formats
currently
in
use
to
describe
media
resources.
Please
send
comments
about
Ideally,
the
mappings
defined
in
this
document
to
public-media-annotation@w3.org
mailing
list
(
public
archive
).
Publication
as
a
Working
Draft
does
not
imply
endorsement
by
would
preserve
the
W3C
Membership.
This
is
semantics
of
a
draft
document
and
may
metadata
item
across
metadata
formats.
In
reality,
however,
this
cannot
be
updated,
replaced
or
obsoleted
by
other
documents
at
any
time.
It
easily
achieved:
there
is
inappropriate
to
cite
this
document
as
other
than
work
often
a
difference
in
progress.
This
document
was
produced
the
extension
of
what
is
covered
by
a
group
operating
under
the
5
February
2004
W3C
Patent
Policy
.
W3C
maintains
elements
(or
terms)
from
different
formats.
This
means
that
a
public
list
of
any
patent
disclosures
made
in
connection
with
mapping
between
the
deliverables
of
Ontology's
property
and
the
group;
elements
from
two
different
formats
that
page
also
includes
instructions
for
disclosing
have
such
a
patent.
An
individual
who
has
actual
knowledge
of
difference
will
not
allow
a
patent
which
semantic-preserving
mapping.
For
example,
the
individual
believes
contains
Essential
Claim(s)
must
disclose
information
accordance
with
section
6
of
the
W3C
Patent
Policy
.
Table
of
Contents
1
Introduction
1.1
Purpose
Exchangeable
Image
File
Format,
or
1.2
Formats
as
a
reference,
will
induce
a
certain
loss
in
semantics.
Mechanisms
for
correcting
for
this
loss
are
beyond
the
scope
1.3
Formats
out
of
scope
2
Terminology
and
Identifiers
this
document.
2.1
Terminology
2.2
Identifiers
The
Ontology
defines
3
Property
value
types
definitions
3.1
Basic
property
value
types
3.1.1
URI
3.1.2
Date
4
Property
definition
4.1
Description
of
approach
commonly
used
to
describe
media
resources.
The
namespace
for
the
property
definitions
Ontology
is
,
which
is
identified
with
the
4.2
Property
mapping
table
4.2.1
Rationale
regarding
mapping
table
4.2.1.1
Semantic
Level
Mappings
4.2.1.2
Syntactic
Level
Mappings
4.2.1.3
Mapping
expression
4.2.2
The
mapping
table
"ma"
prefix
in
this
document.
Although
some
of
the
properties
can
appear
to
be
redundant
with
This
section
Dublin
Core
is
informative.
This
document
defines
only
"Ontology
vocabularies
for
Media
Object
1.0".
It
provides
a
core
vocabulary
which
consists
of
a
common
mapping
is
defined.
The
Dublin
Core
set
does
not
cover
all
needs
of
properties
to
describe
the
basic
metadata
needed
for
media
entities
,
and
the
semantic
links
between
their
values
in
different
existing
vocabularies.
For
example
creator
is
a
common
property
that
is
supported
in
several
existing
metadata
formats,
and
could
therefore
Media
Ontology;
this
specification
would
be
part
at
least
an
extension
of
Dublin
Core.
More
importantly,
the
core
vocabulary
defined
by
the
Ontology.
The
semantic
links
Dublin
Core
properties
have
been
created
with
a
set
of
the
ontology
defines
the
interrelations
between
restrictions.
While
these
restrictions
are
in
general
somewhat
loose,
this
specification
required
in
different
formats.
For
example
of
the
property
dc:creator
from
Dublin
Core
can
be
mapped
Ontology,
related
to
its
use
in
an
API
(see
The
Media
Ontology
(i.e.
the
property
artist
core
set
of
properties
and
mappings
defined
in
EXIF
.
This
this
specification)
provides
the
basic
information
needed
by
targeted
applications
(see
Object
Ressource
1.0
the
interoperability
among
the
various
kinds
of
metadata
formats
related
to
entities
resources
In
addition,
the
ontology
will
be
The
Ontology
is
accompanied
by
an
API
(see
elements
defined
by
the
ontology.
This
initial
version
of
this
document
contains
only
its
elements.
Furthermore
a
limited
set
Semantic
Web
compatible
implementation
of
properties
with
corresponding
semantic
mappings,
the
Ontology
is
available
which
are
listed
in
section
1.2
Formats
is
presented
in
scope
.
Nevertheless
it
Section
7
of
this
document.
This
implementation
uses
the
Semantic
Web
ontology
languages
RDF/OWL
and
its
derivation
from
the
core
vocabulary
is
being
published
presented
in
detail
with
the
aspiration
it.
The
properties
defined
in
this
document
are
used
to
gather
wide
feedback
describe
media
resources
that
are
available
on
the
general
direction
of
web.
Media
resources
can
denote
both
the
Working
Group.
In
particular
we
would
like
to
encourage
feedback
on
section
4
Property
definition
.
1.1
Purpose
of
this
specification
This
specification
defines
ontology
for
cross-community
data
integration
abstract
concept
of
information
related
to
a
media
entities
on
resource
(e.g.,
the
Web.
The
purpose
movie
"Notting
Hill")
as
well
as
a
specific
instance
(e.g.,
a
certain
file
with
an
MPEG-4
encoding
of
the
ontology
is
to
help
circumventing
English
version
of
"Notting
Hill"
with
French
subtitles).
For
the
current
proliferation
sake
of
video
metadata
formats
by
providing
full
or
partial
translation
and
mapping
simplicity,
we
do
not
make
distinctions
between
the
existing
formats.
these
different
levels
of
abstraction
that
exist
in
some
formats
(e.g.,
[
1.2
In
specification
the
section
are
informative.
The
following
table
lists
the
formats
related
to
media
entities
on
that
were
selected
as
in-scope
of
a
potential
mapping
from
the
Web
have
been
taken
into
account
.
Note:
Media
Ontology,
along
with
the
identifiers
which
are
used
as
prefixes
to
identify
them
in
this
specification.
This
specification
is
based
We
distinguish
multimedia
metadata
formats
that
focus
on
a
review
the
description
of
existing
formats
and
multimedia
resources
from
multimedia
container
formats.
In
the
case
of
the
latter,
only
few
technical
properties
are
relevant
for
the
Ontology
for
Media
Resources,
because
of
they
provide.
This
review
does
not
aim
to
be
complete,
and
widespread
usage.
Very
specific
properties
are
out
of
the
scope
of
this
specification
does
not
aim
to
cover
all
properties
defined
| Identifier | Format | Example | Reference |
|---|---|---|---|
| cl11 |
CableLabs
1.1
|
cl11:Writer_Display | |
| dig35 |
DIG35
|
dig35:ipr_name/ipr_person@description='Image Creator' | |
| dc | Dublin Core | dc:creator | |
| ebucore |
EBUCore
|
ebucore:creator | |
| exif |
EXIF
| exif:Artist | |
| id3 | ID3 | id3:TCOM | |
| iptc |
IPTC
|
iptc:Creator | |
| lom21 |
LOM
| lom21:LifeCycle/Contribute/Entity | |
| mrss | Media RSS | mrss:credit@role='author' | |
| mpeg7 | MPEG-7 | mpeg7:CreationInformation/Creation/Creator/Agent | |
| ogg | OGG | ogg:track=serialno/vorbiscomment/title and ogg:track=serialno/skeleton/title | |
| qt |
QuickTime
|
qt:com.apple.quicktime.author | |
| dms | DMS-1 | dms:Participant/Person | |
| ttml | TTML | ttml:actor | |
| tva |
TV-Anytime
|
tva:CredistsList/CredistItem | |
| txf | TXFeed | txf:author | |
| xmp | XMP | xmp:CreatorTool | |
| yt | YouTube Data API Protocol | yt:author |
| Identifier | Format | Example | Reference |
|---|---|---|---|
| 3gp | 3GP | 3gp:udta/auth | |
| flv | FLV |
|
|
| qt | QuickTime | qt:com.apple.quicktime.author | |
| mp4 | MP4 | mp4:udta/cprt | |
| ogg | OGG | ogg:track=serialno/vorbiscomment/title and ogg:track=serialno/skeleton/title | |
| webm | WebM | webm:segment=id/track=id/Language |
The
following
formats
have
been
decided
to
be
are
out
of
scope
for
this
specification.
MPEG-21
Editorial
note
This
list
needs
to
be
brought
sync
with
the
mapping
table.
2
Terminology
and
Identifiers
narrower
sense.
2.1
Terminology
This
document
contains
normative,
non-normative,
and
informative
sections.
The
parts
of
this
document
that
define
the
Ontology,
as
well
as
the
syntactic
and
semantic
level
mappings
between
elements
from
existing
formats
and
the
core
properties
defined
in
this
document,
are
normative,
and
are
marked
as
such.
For
normative
sections
only,
the
keywords
MUST
,
MUST
NOT
,
SHOULD
"MUST",
"MUST
NOT",
"REQUIRED",
"SHALL",
"SHALL
NOT",
"SHOULD",
"RECOMMENDED",
"MAY",
and
SHOULD
NOT
"OPTIONAL"
are
to
be
interpreted
as
described
in
RFC2119
[
A
RFC
2119
A
media
entity
formal
definition
of
an
ontology
is
as
follows.
"An
ontology
is
either
a
conceptual
object
(for
example
formal,
explicit
specification
of
a
shared,
often
machine-readable,
vocabulary.
Its
meaning,
in
the
play
Hamlet
by
Shakespeare)
or
form
of
entities
and
relationships
between
them,
intends
to
describe
some
knowledge
in
a
concrete
object:
given
domain.
Formal
refers
to
the
fact
that
the
ontology
should
be
representable
in
a
media
file
formal
grammar.
Explicit
means
that
the
entities
and
relationships
used,
and
the
constraints
on
their
use,
are
precisely
and
unambiguously
defined
in
a
declarative
language
suitable
for
knowledge
representation.
Shared
means
that
all
users
of
one
interpretation
an
ontology
will
represent
a
concept
using
the
same
or
equivalent
set
of
Hamlet,
possibly
online
entities
and
possibly
identified
by
a
URL.
These
two
types
are
respectively
refered
relationships.
Domain
refers
to
the
content
of
the
universe
of
discourse
being
represented
by
the
terms
ontology"
[
resource
and
representation
an
ontology
is
used:
a
shared
vocabulary.
The
vocabulary
in
question
is
the
RDF
Schema
vocabulary
.
We
adopt
list
of
core
properties
(relationships)
defined
here
(prefixed
ma
in
this
terminology
document);
its
machine-readable
format
is
specified
in
order
the
following
consistent
considered
to
be
conformant
with
this
specification,
as
long
as
they
comply
to
the
terminological
choices
definition
of
the
properties
listed
in
the
following
A
media
resource
is
any
physical
or
logical
resource
that
can
be
identified
using
a
Uniform
Resource
Identifier
(URI),
as
defined
by
[
closely
related
to
our
own
activity.
Another
way
of
expressing
one
or
more
media
content
types.
Note
that
[
difference
and
thus
term
encompasses
the
variety
abstract
notion
of
a
movie
(e.g.,
Notting
Hill)
as
well
as
the
binary
encoding
of
media
entities
taken
into
account
in
this
Working
Group
is
movie
(e.g.,
the
notions
MPEG-4
encoding
of
Work
and
Item
Notting
Hill
on
a
DVD),
or
any
intermediate
levels
of
abstraction
(e.g.,
the
director's
cut
or
the
plain
version
of
the
Notting
Hill
movie).
Although
some
ontologies
(
FRBR
(Note:
FRBR
also
considers
two
other
"intermediate"
entity
status
between
a
Work
and
an
Item)
[
Definition
:
A
property
is
an
element
from
an
existing
metadata
format
for
describing
entities
on
the
web.
resources
Working
Group.
specification.
For
example,
the
Dublin
Core
creator
Entity
Resource
value:
literal
value
or
another
resource.
In
the
above
example,
the
representation
resource
with
the
value
of
its
creator
(Dublin
property.
In
this
example,
Dublin
Core
specifies:
does
this
by
defining
the
Creator
creator
include
a
person,
an
organization,
or
a
service.",
this
value
service".
Properties
can
be
specified
as
a
simple
string
have
structured
or
as
the
URI
representing
the
creator.
unstructured
values.
The
set
of
properties
selected
to
be
part
of
defined
in
the
Media
Ontology
Core
core
vocabulary
is
listed
in
section
4
Property
definition
A
representation
is
a
time-dependent
document,
or
part
For
the
purposes
of
this
document,
identifiable
by
a
URI.
For
example:
portion
of
raw
data
of
function
that
transforms
information
represented
in
one
schema
using
one
format
to
information
in
a
video,
an
image,
an
audio,
different
schema
that
uses
a
text,
any
other
time-aligned
data
or
different
format.
In
this
document,
a
composition
of
them.
[
Definition
:
Mapping]
The
notion
of
Mapping
refers
to
the
description
set
of
relations
mappings
are
defined
between
elements
a
subset
of
metadata
schemas;
in
our
case
the
mapping
concerns
the
Vocabularies
"in
scope",
scope"
Vocabularies
and
the
Ontology.
Ontology
that
is
defined
in
this
document.
These
Mappings
mappings
are
presented
in
section
4.2
Property
mapping
table
Property
value
types
are
the
data
types
of
the
values
used
in
for
a
.
sec.
3
Property
value
types
definitions
.
section
relying
mostly
dependent
on
XML
Schema
data
types
[
Currently,
the
data
types
of
property
values
that
used
in
this
document
are
defined
in
terms
of
XML
Schema
2
1.1,
part
2.
Applications that wish to be conformant with this specification MUST use the data types specified in this section for property values that are defined in this specification.
"A
Uniform
Resource
Identifier",
or
URI,
is
defined
in
[
2.2
Identifiers
A
String
value
MUST
be
represented
using
the
XML
Schema
An
Integer
value
MUST
be
represented
using
the
XML
Schema
A
Decimal
value
SHOULD
be
represented
using
the
XML
Schema
A
Date
value
MUST
be
represented
using
one
of
formats
the
specific
date/time
data
types
of
XML
Schema,
depending
on
the
available
precision:
This
list
of
core
properties
has
been
defined
by
creating
an
initial
set
of
mappings
from
the
list
of
The
following
table
lists
identifiers
which
are
used
to
identify
formats
ranking
of
the
core
properties
by
expected
importance,
as
determined
by
the
use
cases
defined
in
The following information is available for each property:
Name
Editorial
note
Description
Several
properties
in
this
specification
are
defined
as
complex
types,
consisting
of
a
tuple
of
attributes.
This
list
needs
is
used
to
support
qualifiers
and
optional
attributes.
Hence,
a
special
syntax
has
been
defined
to
accommodate
this
requirement,
and
is
explained
below.
All
properties
names
are
intentionally
in
singular
form
and
MUST
contain
only
a
single
value.
However,
multiple
instances
of
a
property
MAY
be
used.
In
addition,
each
property
MAY
have
an
associated
language
attribute,
which
can
be
used
to
enable
several
instances
of
that
property
to
be
brought
defined
in
sync
with
different
languages.
The
following
syntax
is
used
for
the
mapping
table.
type
descriptions:
( ) (parentheses) are used to indicate a attribute/value pair
| (vertical bar) is used to indicate a choice between different values
{ } (curly brackets) are used to define a complex type, i.e., a tuple of attribute/value pairs
? (question mark) is used to indicate an optional element
contributor { (attName="contributor", attValue="URI" | "String"), (attName="role", attValue="URI" | "String")? } is interpreted as a complex type that has two elements. The first identifies the contributor of a media resource by using a URI or a string. The second specifies an optional role, which is defined by a string. Elements are comma separated, and the collection of elements that makes up the complex type is enclosed in curly brackets.
| Name | Type definition | Description |
|---|---|---|
|
| ||
| identifier | (attName="identifier", attValue="URI") |
|
| title | { (attName="title", attValue="String"), (attName="type", attValue="URI" | "String")? } |
|
| language | (attName="language", attValue="URI" | "String") |
The
language
used
in
the
resource.
We
recommend
to
use
a
controlled
vocabulary
such
as
[
|
| locator | (attName="locator", attValue="URI") |
|
|
| ||
| contributor | { (attName="contributor", attValue="URI" | "String"), (attName="role", attValue="URI" | "String")? } |
|
| creator | { (attName="creator", attValue="URI" | "String"), (attName="role", attValue="URI" | "String")? } |
|
| date | { (attName="date", attValue="Date"), (attName="type", attValue="URI" | "String")? } | A tuple defining the date and time that the resource was created. The type can be used to optionally define the category of creation date (e.g., release date, date recorded, or date edited). |
| location | { (attName="name", attValue="URI" | "String")?, (attName="longitude", attValue="Decimal")?, (attName="latitude", attValue="Decimal")?, (attName="altitude", attValue="Decimal")?, (attName="coordinateSystem", attValue="URI" | "String")? } |
A
tuple
identifying
a
name
or
a
set
of
geographic
coordinates,
in
a
given
system,
that
describe
where
the
resource
has
been
created,
developed,
recorded,
or
otherwise
authored.
The
name
can
be
defined
using
either
a
URI
(recommended
best
practice)
or
plain
text.
The
geographic
coordinates
include
longitude,
latitude
and
an
optional
altitude
information,
in
a
given
geo-coordinate
system
(such
as
the
|
|
| ||
| description | (attName="description", attValue="String") |
|
| keyword | (attName="keyword", attValue="URI" | "String") | A concept, descriptive phrase or keyword that specifies the topic of the resource, using either a URI (recommended best practice) or plain text. In addition, the concept, descriptive phrase, or keyword contained in this element SHOULD be taken from an ontology or a controlled vocabulary. |
| genre | (attName="genre", attValue="URI" | "String") |
The
category
of
the
content
of
the
resource,
using
either
a
URI
(recommended
best
practice)
or
plain
text.
In
addition,
the
genre
contained
in
this
element
SHOULD
be
taken
from
an
ontology
or
controlled
vocabulary,
such
as
the
|
| rating | { (attName="value", attValue="Decimal"), (attName="ratingSystem", attValue="URI" | "String")?, {(attName="min", attValue="Decimal"), (attName="max", attValue="Decimal")}? } |
|
|
| ||
| relation | { (attName="target", attValue="URI" | "String"), (attName="type", attValue="URI" | "String")? } |
|
| collection | (attName="collection", attValue="URI" | "String") | The name of the collection (using either a URI or plain text) from which the resource originates or to which it belongs. We recommend to use a URI, as a best practice. |
|
| ||
| copyright | { (attName="copyright", attValue="String"), (attName="holder", attValue="URI" | "String")? } |
|
| policy | { (attName="statement", attValue="URI" | "String"), (attName="type", attValue="URI" | "String")? } |
A
tuple
containing
a
policy
statement
either
human
readable
as
a
string
or
machine
resolvable
as
a
URI,
and
the
type
of
the
policy
to
provide
more
information
as
to
the
nature
of
the
policy.
See
|
|
| ||
| publisher | (attName="publisher", attValue="URI" | "String") |
|
| targetAudience | { (attName="audience", attValue="URI" | "String"), (attName="classificationSystem", attValue="URI" | "String")? } | A tuple identifying the audience being addressed (demographic class, parental guidance group, or geographical region) and an optional classification system (e.g., a parental guidance issuing agency). . |
|
| ||
| fragment | { (attName="identifier", attValue="URI"), (attName="role", attValue="URI" | "String")? } |
|
| namedFragment | { (attName="identifier", attValue="URI"), (attName="label", attValue="String") } |
|
| Technical Properties | ||
| frameSize | { (attName="width", attValue="Decimal"), (attName="height", attValue="Decimal"), (attValue="unit", attValue="String")? } |
|
| compression | (attName="compression", attValue="URI" | "String") |
The
compression
type
used.
For
container
files
(e.g.,
QuickTime,
AVI),
the
compression
is
not
defined
by
the
format,
as
a
container
file
can
have
several
tracks
that
each
use
different
encodings.
In
such
a
case,
several
compression
instances
should
be
used.
Thus,
querying
the
compression
property
of
the
track
media
|
| duration | (attName="duration", attValue="Decimal") |
|
| format | (attName="format", attValue="URI" | "String") |
|
| samplingRate | (attName="samplingRate", attValue="Decimal") |
|
| frameRate | (attName="frameRate", attValue="Decimal") | The video frame rate. The units are defined to be frames/second. |
| averageBitRate | (attName="averageBitRate", attValue="Decimal") | The average bit rate. The units are defined to be kbps. |
| numTracks | { (attName="number", attValue="Integer"), (attName="type", attValue="String")? } |
|
A number of these properties use qualifiers to define subtypes and roles: identifier, title, contributor, creator, date, relation, collection, policy, fragment and numTracks. In addition, the location, rating, copyright, and frameSize properties use optional elements to define the unit of measure of their values, the ranges that the values of these elements can have, or other supplementary information. All subtype and role qualifiers for these properties are optional. The set of possible values for subtypes is not normative. However, whenever possible, values defined in an existing controlled vocabulary or classification scheme SHOULD be used.
| Example | Property | Attribute name | Value | Comment |
|---|---|---|---|---|
| Example 1 |
|
|
| ITU-H264 and G711 are defined by example.org (who also defined a URN to identify their naming conventions), and by example.net (who use a URL to identify theirs). |
|
|
|
| ||
|
|
|
|
|
|
|
|
|
|
|
|
| Example 4 |
|
|
| layer 2 or 3 compression, SMPTE |
|
|
|
| ||
|
|
|
|
|
|
|
|
|
|
| AVC compression, IPTC |
URI
"Uniform
Resource
Identifier"
are
defined
in
[
RFC
3986
].
In
this
specification
the
term
URI
is
used
since
it
is
well
known.
However
the
term
is
used
as
meaning
IRIs
"Internationalized
Resource
Identifiers
(IRIs)"
[
RFC
3987
],
that
is
URIs
which
may
contain
non-escaped
characters
other
than
ASCII.
The
data
type
is
anyURI
.
3.1.2
Date
"type
definition"
of
the
policy
property
would
include:
policy.statement
:
A
Date
value
is
represented
using
human-readable
description
of
the
XML
Schema
dateTime
data
type.
4
Property
definition
This
section
is
normative.
4.1
Description
Policy
(string)
or
an
Identifier
of
approach
for
the
property
definitions
Policy
(URI)
policy.type
:
The
following
information
is
available
for
each
property:
rough
description
category
of
purpose
the
Policy
(URI)
property
value
types
Recommended
values
for
policy.type
is
the
Meta
information
from
the
XHTML
Vocabulary
(http://www.w3.org/1999/xhtml/vocab/#)
mappings
to
existing
formats
4.2
The
copyright
would
naturally
be
mapped
into
policy.statement
Examples:
| Property | Attribute name | Value |
|---|---|---|
| policy | statement | Copyright PLING Inc 2010. All Rights Reserved |
| type | http://www.w3.org/1999/xhtml/vocab/#copyright | |
| policy | statement | http://p3pbook.com/examples/10-4.xml |
| type | http://www.w3.org/1999/xhtml/vocab/#p3pv1 | |
| policy | statement | http://odrl.net/license/license.xml |
| type | http://www.w3.org/1999/xhtml/vocab/#license | |
| policy | statement | http://creativecommons.org/licenses/by/3.0/ |
| type | http://www.w3.org/1999/xhtml/vocab/#license |
As
a
first
step
to
build
The
mappings
between
the
Media
ontology,
Ontology
and
a
set
subset
of
commonly
supported
properties
by
the
aforementioned
"in-scope"
vocabularies
has
been
listed.
This
list,
henceforth
referred
to
as
"Core
Media
Properties
list",
is
of
this
specification
specify
both
the
basis
for
vocabularies
matching.
Its
namespace
is
"ma",
for
Media
Annotation
Working
Group.
We
provide
a
first
set
semantic
and
some
elements
of
mapping
propositions
the
syntactic
correspondences
between
the
Media
Ontology
properties
and
the
elements
of
a
given
vocabulary.
The
vocabularies
taken
into
account
selected
were
those
that
were
deemed
to
be
the
most
popular
and
this
list.
These
mappings
have
double
nature:
semantic
useful
regarding
the
proposed
Use
Cases
(see
syntactic.
4.2.1.1
Requirements
for
Ontology
and
API
for
Media
Ressource
1.0
The
presented
mappings
are
"one
way"
so
far,
i.e.
uni-directional
mappings,
because
the
semantics
is
of
a
relationship
between
one
or
more
items
the
elements
being
mapped
from
the
vocabulary
considered
and
one
or
more
same
Media
Ontology
property
from
our
list.
may
be
very
different
across
formats.
For
example,
in
XMP
,
standard)
are
mapped
to
ma:copyright;
in
EXIF
,
standard
[
Copyright
same
property
is
mapped
to
ma:copyright.
Nothing
from
these
mappings
of
semantic
relationships
between
the
properties
elements
defined
in
the
XMP
and
in
EXIF.
This
"Core
Media
Properties
list"
can
be
considered
as
the
minimal
requirement
for
describing
media
content.
EXIF
standards.
The
mappings
that
have
been
taken
into
account
have
different
semantics:
the
properties
semantics
that
have
one
of
the
different
vocabularies
can
be
following
four
characteristics:
Exact
matches:
match:
the
semantics
of
the
two
properties
are
equivalent
in
most
of
the
all
possible
contexts.
For
example,
ma:title
matches
the
semantics
of
the
property
vra:title.
matches
the
semantics
of
the
property
More
specific:
the
property
of
the
vocabulary
taken
into
account
has
a
semantic
associated
semantics
that
takes
into
account
only
contain
a
subset
superset
of
the
possibilities
semantics
expressed
by
the
property
defined
in
this
Working
Group.
specification.
For
example
in
DIG35
,
ma:publisher
it
is
they
are
mapped.
More
generic:
the
inverse
of
the
above,
meaning
that
the
property
of
the
vocabulary
taken
into
account
has
a
semantic
associated
semantics
that
is
broader
than
the
property
defined
in
this
Working
Group.
specification.
For
example,
the
DIG35
ma:location.
Related:
the
two
properties
are
related
in
a
way
that
is
relevant
for
some
use
cases,
but
this
relation
has
no
defined
and/or
commonly
applied
semantics.
For
example,
in
Media
RSS,
ma:creator.
4.2.1.2
This list of relations between vocabularies (or informal mappings) and the "Core Media Properties list" is published as a table. Feedback from people or companies actually using the different vocabularies in communities that are currently using the different vocabularies is very welcome; if such feedback is received, it will be incorporated into an updated of this specification.
Syntactic
level
mappings
declare
define
the
correspondence
between
two
semantically
equivalent
similar
properties
but
with
a
that
have
different
syntactic
expression.
It's
most
evident
expressions,
but
(roughly)
similar
associated
semantics.
For
example,
one
important
use
case
is
the
date
formatting,
where
the
format
of
the
date
and/or
time
used
is
different
in
two
vocabularies,
but
some
others
may
appear.
4.2.1.3
the
overall
semantics
(identifying
a
date
and/or
time)
is
the
same.
Once
the
matching
model
has
been
achieved,
it
has
to
be
expressed.
This
The
mapping
expression
correspond
with
corresponds
to
the
former
paragraphs
acts
concrete
implementation
or
representation
of
the
mappings
defined
in
the
previous
paragraph,
both
at
a
semantic
level
and
at
syntactic
one.
In
the
context
of
the
W3C
Semantic
Web
activity,
currently
a
Candidate
Recommendation
that
of
the
W3C
Semantic
Web
activity
which
defines
a
vocabulary
for
representing
Knowledge
Organization
Systems
(i.e.
vocabularies)
Systems,
such
as
vocabularies,
and
relationships
amongst
them.
In
skos:exactMatch,
skos:narrowMatch,
skos:broaderMatch
skos:relatedMatch.
Some
more
fine
grained
definition
A
future
version
of
this
specification
may
include
additional
information
about
the
properties
has
still
to
properties.
For
example,
some
restrictions
might
be
done:
we
need
added
to
agree
on
the
properties'
names,
define
their
formal
properties
(if
a
set
of
mappings
(e.g.,
if
they
are
symmetric,
etc)
and
the
type
of
value
expected,
symmetric)
to
enhance
more
efficient
concrete
mappings,
in
the
API.
This
list
of
relations
between
vocabularies
(or
informal
mappings)
and
the
"Core
Media
Properties
list"
is
published
as
a
table;
its
purpose
is
mappings.
If
such
changes
are
implemented,
every
effort
will
be
made
to
get
feedback
from
the
communities
produce
a
new
and
revised
specification
that
are
currently
using
the
different
vocabularies:
the
people
or
companies
actually
using
is
backwards-compatible
with
the
different
vocabularies
could
proof-read
our
interpretation
current
version
of
the
vocabularies
and
comment
on
the
proposed
mappings.
this
specification.
The
Core
following
mappings
are
established
from
the
Media
Ontology's
properties
to
various
multimedia
metadata
formats.
This
list
of
properties
formats
is
not
exhaustive
and
if
some
properties
are
judged
closed,
nor
does
it
pretend
to
be
missing
for
different
use
cases
or
in
different
communities,
the
list
will
be
extended.
This
list
has
been
defined
by
making
an
initial
set
exhaustive.
A
future
version
of
this
specification
may
include
additional
mappings
if
a
need
or
use
case
is
established
for
these
new
mappings.
For
each
format
there
is
a
mapping
propositions
from
table
with
the
list
of
vocabularies
in
scope
to
XMP
following
columns.
as
a
pivot
vocabulary.
From
this
original
mapping
table,
it
has
been
checked
which
of
properties
were
supported
by
most
name
of
the
vocabularies,
and
which
ones
were
judged
useful
by
the
members
of
property
being
mapped
to,
like
group
present
at
semantic
relation.
Possible
values
are:
more
specific,
more
general,
related,
exact,
non
applicable
(N/A).
Third
column:
the
Face
to
Face
meeting
in
Barcelona
.
A
list
name
of
properties
by
a
cross
validation
between
the
member's
opinion
and
format
specific
property.
popularity
abbrevation
of
the
properties
across
the
vocabularies
has
been
selected
in
order
to
get
some
level
of
objectiveness.
specification
wich
defines
that
property.
4.2.2
The
table
Editorial
note
Here
put
the
mapping
table
property
in
some
form
the
format.
Not
given
for
all
formats.
The
following
mappings
are
established
between
from
the
Media
Ontology's
properties
to
various
multimedia
metadata
formats
with
core
vocabulary
of
MA
WG
as
pivot.
container
formats.
This
list
of
container
formats
is
not
closed,
nor
does
it
pretend
to
be
exhaustive
and
that
exhaustive.
A
future
version
of
this
specification
may
include
additional
mappings
if
a
need
or
use
case
is
established
for
these
new
mappings.
The
technical
properties
for
the
group
still
looks
at
rationale
QuickTime
container
are
available
in
the
The
technical
properties
for
including
and
excluding
formats
to
be
considered
the
OGG
container
are
available
in
the
final
table;
table
Summary
<?xml version="1.0"?> <powder xmlns="http://www.w3.org/2007/05/powder#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ma="http://www.w3.org/ns/ma-ont#">XMP<attribution> <issuedby src="http://example.com/company.rdf#me" /> <issued>2007-12-14T00:00:00</issued> </attribution> <dr> <iriset> <includehosts>example.com</includehosts> <includepathstartswith>/movies/sci-fi/</includepathstartswith> </iriset> <descriptorset> <ma:hasGenre rdf:resource="http://example.com/ontology.rdf#sf" /> <ma:hasPublisher rdf:resource="http://example.com/company.rdf#me" /> <displaytext>Movies in this section of the website are all in the science fiction genre</displaytext> <displayicon src="http://example.com/sf-icon.png" /> </descriptorset> </dr> </powder>
ID3
Concerning
external
subtitles,
using
relation
is
the
recommended
approach.
The
identifier
attribute
contains
the
URL
of
the
subtitle
file,
and
the
relation
type
qualifies
it
as
a
subtitle
relation.
The
value
should
be
a
URI,
but
could
also
be
a
string.
It
is
recommended
to
use
a
controlled
vocabulary
for
the
type
of
the
relation.
Embedding
of
subtitles
is
not
a
use
case
that
has
been
considered,
however
it
is
possible.
The
mechanism
used
to
specify
timed
metadata
is
to
specify
fragments
identified
by
Media
Fragment
URIs
[
iTunes
QT
To
summarize,
there
are
three
options
for
dealing
with
subtitles:
Link
to
external
subtitle
file
using
fragment,
with
type
subtitle
and
a
Timed
Text
Markup
Language
(TTML)
[
SearchMonkey
Subtitles
can
be
embedded
in
a
media
file,
in
which
case
they
can
be
described
as
a
track
media
fragment
using
fragment
and
Media
Fragment
URIs
[
MediaRDF
LOM
Subtitles
could
be
embedded
by
using
title
with
a
type
qualifier
for
subtitle.
A
list
of
time
media
fragments
is
defined
and
each
fragment
is
annotated
using
title.
METS
Although
the
last
option
is
a
way
of
embedding
subtitles
it
is
not
recommended.
Instead,
a
dedicated
format
such
as
TTML
or
WebSRT
should
be
used
for
the
subtitles
and
referenced.
EXIF
Time
based
annotations
are
a
possible
and
the
following
two
cases
are
covered
by
the
specification:
CableLabs
1.1
use
description
for
a
textual
description
of
the
media
resource
(or
a
fragment).
CableLabs
2.0
use
relation
to
link
to
a
RDF
file
or
named
graph
containing
the
annotation
for
the
media
resource
(or
fragment).
DIG35
At
the
time
of
writing
this
specification,
there
no
solution
for
embedding
a
set
of
triples
into
one
of
the
properties
of
the
Ontology
for
Media
Resources
1.0.
The
summary
of
a
discussion
with
the
Semantic
Web
Coordination
Group
is
that
named
graphs
could
be
a
solution
to
this
issue,
but
there
is
no
standard
syntax
for
expressing
them,
to
which
this
specification
could
refer.
Such
a
syntax
might
find
its
way
into
RDF
2.0.
Thus
the
embedding
of
triples
into
media
annotation
elements
is
excluded
until
a
standard
syntax
for
named
graphs
is
available.
MIX
FRBR
Captions
and
signing
of
a
media
resource
can
be
provided
in
different
forms,
the
most
typical
being:
MediaRSS
To
account
for
this
diversity,
the
RDF
ontology
does
not
link
<tt>ma:hasTrack</tt>
with
<tt>ma:hasCaptioning</tt>
or
<tt>ma:hasSigning</tt>
.
The
last
two
can
link
a
media
resource
to
any
fragment,
e.g.
a
spatial
fragment
of
the
video
track
where
the
signing
is
located,
or
even
an
external
file
considered
as
a
fragment
of
the
resource.
If
the
fragment
is
also
a
track,
nothing
prevents
to
link
it
with
both
properties
<tt>ma:hasCaptioning</tt>
and
<tt>ma:hasTrack</tt>
.
TXFeed
For
example,
the
following
RDF
describes
a
video
with
embeded
signing,
subtitles
as
an
external
file,
and
a
track
containing
audio-description
(caption
for
accessibility):
<video.ogv> a ma:MediaResource ;
ma:hasSigning <video.ogv#xywh=percent:70,70,90,90>;
ma:hasSubtitling <./video.srt> ;
ma:hasAudioDescription <video.ogv?track=subtitle> ;
ma:hasTrack <video.ogv?track=subtitle> ;
YouTube
The
core
set
of
properties
proposed
in
VRA
The
four
language
codes
could
be
directly
applied
to
the
video
file,
using
the
language
core
property
<tt>ma:hasLanguage</tt>
in
the
IPTC
If
one
wants
to
keep
the
complete
information,
the
recommended
option
is
to
assign
each
language
to
the
appropriate
fragment
of
the
video,
using
[
The corresponding RDF would be:
<video.ogv> a ma:MediaResource ;
ma:hasTrack <video.ogv#track=audio>,
<video.ogv#track=subtitle>;
ma:hasSubtitling <video.ogv#track=subtitle> ;
ma:hasSigning <video.ogv#xywh=percent:70,70,90,90> .
TVA
<video.ogv#track=audio> a ma:AudioTrack ;
ma:hasLanguage [ rdfs:label "en-GB" ] ;
ma:hasFragment <video.ogv#track=audio&t=10,20> .
<video.ogv#track=audio&t=10,20> a ma:MediaFragment ;
ma:hasLanguage [ rdfs:label "fr" ] .
EBUCore
<video.ogv#track=subtitle> a ma:DataTrack ;
ma:hasLanguage [ rdfs:label "es" ] .
<video.ogv#xywh=percent:70,70,90,90> a ma:MediaFragment ;
ma:hasLanguage [ rdfs:label "bfi" ] .
EBUP
MPEG7
This
section
presents
an
implementation
of
the
Ontology
for
Media
Resources
as
a
Semantic
Web
ontology.
At
first
a
namespace
for
the
Ontology
is
defined
(Section
7.1).
Secondly,
an
implementation
guideline
is
given
which
details
how
the
core
vocabulary
defined
in
this
specification
relates
to
the
RDF
vocabulary
(Section
7.2).
Finally
Section
7.3
presents
an
RDF
vocabulary
which
implements
the
abstract
ontology
using
RDF
and
OWL.
The
ontology
is
a
valid
OWL2
DL
ontology
and
it
can
be
directly
used
to
describe
media
resource
on
the
Web
in
a
Semantic
Web
and
Linked
Data
compatible
way.
The
ontology
has
been
built
using
standard
ontology
engineering
methodologies
in
a
small
expert
group
inside
the
MAWG
working
group.
The
namespace
of
the
Ontology
for
Media
Resources
1.0
is
defined
by
this
URI:
.
Applications
that
are
compliant
with
this
specification
MUST
use
this
namespace
URI.
SMTPD
As specifications that use this namespace URI progress through the standardization process, they MUST use the same namespace URI. This namespace URI is expected to remain the same throughout the evolution of this ontology, even in the case new properties are added to it, so long as it remains backwards compatible. If however a new version were produced that was not backwards compatible, the WG reserves the right to change the namespace URI.
The
ma
prefix
name
is
associated
with
the
namespace
URI
in
this
document.
The
following
table
gives
the
correspondence
between
the
core
properties
as
described
in
the
Unless stated otherwise, atomic values are represented by literals while complex values are represented by resources. It follows that, in the general case, properties with complex values are represented by object properties, while properties with simple values are represented by datatype properties. Attributes in complex values are represented by properties of the resource representing the complex value; depending on their semantics, they are represented by datatype or object properties.
The RDF ontology also introduces a number of classes corresponding to the domains and ranges of the corresponding property.
| Identification | |
| identifier |
(
|
| title | ma:title |
| title.title | (value of ma:title) |
| title.type |
(
|
| language |
ma:hasLanguage
(
|
| locator | ma:locator |
| Creation | |
| contributor | ma:hasContributor (see contributor.role ) |
| contributor.contributor |
(URI
or
rdfs:label)
(
|
| contributor.role |
(
|
| creator | ma:hasCreator (see creator.role ) |
| creator.creator |
(URI
or
rdfs:label)
(
|
| creator.role |
(
|
| date | ma:date |
| date.date |
(value
of
ma:date)
(
|
| date.type |
(
|
| location | ma:hasRelatedLocation (see location.name ) |
| location.name |
(URI
or
rdfs:label)
(
|
| location.longitude | ma:locationLongitude |
| location.latitude | ma:locationLatitude |
| location.altitude | ma:locationAltitude |
| location.coordinateSystem |
ma:hasLocationCoordinateSystem
(
|
| Content description | |
| description | ma:description |
| keyword |
ma:hasKeyword
(
|
| genre |
ma:hasGenre
(
|
| rating | ma:hasRating |
| rating.value | ma:ratingValue |
| rating.ratingSystem | ma:hasRatingSystem |
| rating.min | ma:ratingScaleMin |
| rating.max | ma:ratingScaleMax |
| Relational | |
| relation | ma:hasRelatedResource (see relation.type ) |
| relation.target |
(URI
or
rdfs:label)
(
|
| relation.type |
(
|
| collection |
ma:isMemberOf
(
|
| Rights | |
| copyright |
(
|
| copyright.copyright | ma:copyright |
| copyright.holder | ma:isCopyrightedBy |
| policy | ma:hasPolicy (see policy.type ) |
| policy.statement |
(URI
or
rdfs:label)
(
|
| policy.type |
(
|
| Distribution | |
| publisher |
ma:hasPublisher
(
|
| targetAudience | ma:hasTargetAudience |
| targetAudience.audience |
ma:hasClassification
(
|
| targetAudience.classificationSystem |
ma:hasClassificationSystem
(
|
| Fragment | |
| fragment | ma:hasFragment |
| fragment.identifier | (URI pointed by ma:hasFragment) |
| fragment.role |
(
|
| namedFragment | ma:hasNamedFragment |
| namedFragment.identifier | (URI pointed by ma:hasNamedFragment) |
| namedFragment.label | ma:fragmentName |
| Technical Properties | |
| frameSize |
(
|
| frameSize.width | ma:frameWidth |
| frameSize.height | ma:frameHeight |
| frameSize.unit | ma:frameSizeUnit |
| compression |
ma:hasCompression
(
|
| duration | ma:duration |
| format |
ma:hasFormat
(
|
| samplingRate | ma:samplingRate |
| frameRate | ma:frameRate |
| averageBitRate | ma:averageBitRate |
| numTracks | ma:numberOfTracks |
| numTracks.number | (value of the ma:numberOfTracks property) |
| numTracks.type |
(
|
(1) The identifier of a media resource is represented in RDF by the URI of the node representing that media resource. If a resource is identified by several URI, owl:sameAs should be used.
(2) Different values of this attribute should be represented by subproperties of the original property; the RDF ontology provides such subproperties for the most common cases.
(3) If the value is a string, the RDF property should point to a blank node with that string as its rdfs:label; if the value is a URI, the RDF property should point to a resource with that URI.
(4) The pattern is the same as (3), but the value to consider is that of an attribute of the complex value.
(5) This property has no direct correspondence; the properties corresponding to the attributes of the complex value apply directly to the media resource.
(6)
According
to
The following is the authoritative RDF/OWL representation of the Media Ontology: the Ontology for Media Resources 1.0
&ma-ontology-owl;
CableLabs
VOD
Content
Specification
Version
1.1
The
following
is
the
Turtle
(Terse
RDF
Triple
Language)
[
.
&ma-ontology-owl;
.
2008.
July
2010.
Available
for
download
at
http://www.adobe.com/devnet/xmp/pdfs/XMPSpecificationPart2.pdf
.
[YouTube
Data
API
Protocol]
http://www.adobe.com/content/dam/Adobe/en/devnet/xmp/pdfs/XMPSpecificationPart2.pdf.