Descriptions
about the
CONTENT...
Descriptions
related to
INTELLECTUAL PROPERTY...
Descriptions
identifying
a media asset's
INSTANTIATION...
Descriptions
beyond
the PBCore Metadata
|
|
| Unresolved
Questions
Concerning the PBCore Elements |
|
As version
1.0 of the PBCore has developed, the Dictionary Working Group has encountered
areas where the members could not come to consensus regarding scope
and definitions.
Anticipating the quality and quantity of
responses from the Request for Comments phase of the project, the Dictionary
Working Group decided to forward its concerns to the respondents.
For those PBCore Elements with unresolved
questions, the question or comment has been included at the bottom of
each element's individual attribute page.
For convenience, the same unresolved questions
have been entered on this page in one, long, printable document. You
may use the links below to quickly jump to an individual element's "Unresolved
Question."
|
Unresolved
Questions
|
01.00
Title
Public Broadcasting's programs
and resources are often identified by a hierarchical naming structure.
This can include a Collection Title, Series Title, Episode Title, Program
Title, and Segment Title. Other titles may include Working Title, Project
Title, as well as an overall Packaging Title used in community outreach
or in product distribution and dissemination.
Metadata Dictionary Projects, such as Dublin Core, do not accommodate
a hierarchical naming system for the titles of resources and assets.
They instead allow an agency to identify alternative or related titles
by simply repeating the Title data field multiple times, but with each
instance containing different title information. Another option is to
retain the uniqueness of a data record for an asset and use the data
field labeled "Relation" to express how an asset is related
to titles of a parental, sibling or child hierarchy.
If the PBCore is primarily a data exchange format used
to discover and share information about resources, should we follow
our community's natural instinct, forego the Dublin Core approach, and
instead promote the use of refinements or qualifiers for the "Title"
element that accurately reflect a resource's title hierarchy? For example:
- Title.Packaging
- Title.Project
- Title.Collection
- Title.Series
- Title.Program
- Title.Episode
- Title.Segment
- Title.Excerpt
- Title.Working
For a discussion on the issue of identifying collections,
see http://dublincore.org/groups/collections/
|
01.01
Title.Alternative
TITLE.ALTERNATIVE may need
to be clarified for the Public Broadcasting community. Is it the working
(pre-production) title or is it a commonly understood "aka"
title? If we intend to exchange metadata about a program still in production,
should the program title be tagged/flagged as a working title?
An Alternative Title is usually important to the workflows
within a producing agency, but may not be something published out to
the world via the PBCore for others to search and discover. Is the focus
of the PBCore for metadata exchange of full programs or smaller segments
or objects that are ready for sharing, ready for primetime, if you will?
If so, these assets would always have proper or given titles for the
public or others within the public broadcasting communities to search
and view. That said, there is nothing to prevent a producing agency
from creating metadata fields within their own database management system
that separate out working titles or other non-permanent titles. These
would just not be mapped to the PBCore exchange metadata.
|
01.02
Title.Series
Public Broadcasting's programs
and resources are often identified by a hierarchical naming structure.
This can include a Collection Title, Series Title, Episode Title, Program
Title, and Segment Title. Other titles may include Working Title, Project
Title, as well as an overall Packaging Title used in community outreach
or in product distribution and dissemination.
Metadata Dictionary Projects, such as Dublin Core, do not accommodate
a hierarchical naming system for the titles of resources and assets.
They instead allow an agency to identify alternative or related titles
by simply repeating the Title data field multiple times, but with each
instance containing different title information. Another option is to
retain the uniqueness of a data record for an asset and use the data
field labeled "Relation" to express how an asset is related
to titles of a parental, sibling or child hierarchy.
If the PBCore is primarily a data exchange format used
to discover and share information about resources, should we follow
our community's natural instinct, forego the Dublin Core approach, and
instead promote the use of refinements or qualifiers for the "Title"
element that accurately reflect a resource's title hierarchy? For example:
- Title.Packaging
- Title.Project
- Title.Collection
- Title.Series
- Title.Program
- Title.Episode
- Title.Segment
- Title.Excerpt
- Title.Working
For a discussion on the issue of identifying collections,
see http://dublincore.org/groups/collections/
|
01.03
Title.Program
Public Broadcasting's programs
and resources are often identified by a hierarchical naming structure.
This can include a Collection Title, Series Title, Episode Title, Program
Title, and Segment Title. Other titles may include Working Title, Project
Title, as well as an overall Packaging Title used in community outreach
or in product distribution and dissemination.
Metadata Dictionary Projects, such as Dublin Core, do not accommodate
a hierarchical naming system for the titles of resources and assets.
They instead allow an agency to identify alternative or related titles
by simply repeating the Title data field multiple times, but with each
instance containing different title information. Another option is to
retain the uniqueness of a data record for an asset and use the data
field labeled "Relation" to express how an asset is related
to titles of a parental, sibling or child hierarchy.
If the PBCore is primarily a data exchange format used
to discover and share information about resources, should we follow
our community's natural instinct, forego the Dublin Core approach, and
instead promote the use of refinements or qualifiers for the "Title"
element that accurately reflect a resource's title hierarchy? For example:
- Title.Packaging
- Title.Project
- Title.Collection
- Title.Series
- Title.Program
- Title.Episode
- Title.Segment
- Title.Excerpt
- Title.Working
For a discussion on the issue of identifying collections,
see http://dublincore.org/groups/collections/
|
01.04
Title.Episode
Public Broadcasting's programs
and resources are often identified by a hierarchical naming structure.
This can include a Collection Title, Series Title, Episode Title, Program
Title, and Segment Title. Other titles may include Working Title, Project
Title, as well as an overall Packaging Title used in community outreach
or in product distribution and dissemination.
Metadata Dictionary Projects, such as Dublin Core, do not accommodate
a hierarchical naming system for the titles of resources and assets.
They instead allow an agency to identify alternative or related titles
by simply repeating the Title data field multiple times, but with each
instance containing different title information. Another option is to
retain the uniqueness of a data record for an asset and use the data
field labeled "Relation" to express how an asset is related
to titles of a parental, sibling or child hierarchy.
If the PBCore is primarily a data exchange format used
to discover and share information about resources, should we follow
our community's natural instinct, forego the Dublin Core approach, and
instead promote the use of refinements or qualifiers for the "Title"
element that accurately reflect a resource's title hierarchy? For example:
- Title.Packaging
- Title.Project
- Title.Collection
- Title.Series
- Title.Program
- Title.Episode
- Title.Segment
- Title.Excerpt
- Title.Working
For a discussion on the issue of identifying collections,
see http://dublincore.org/groups/collections/
|
03.00
Subject
The Subject for a resource
may be entered as free-form text or follow selections and the rules
associated with a formal classification scheme for keywords and subject
headings. If formal classification schemes are followed, then the scheme
being employed must also be noted in the metadata associated with a
resource. This means that different agencies will employ different subject
classification schemes depending on their need and custom. Is this problematic
for the public broadcasting community as it shares metadata using the
PBCore?
|
04.00
Description
If the PBCore follows the rules
associated with Dublin Core, we can qualify the element DESCRIPTION
by using the more refined DESCRIPTION.ABSTRACT, DESCRIPTION.TABLEOFCONTENTS,
and DESCRIPTION.PROGRAMRELATEDTEXT.
Alternatively, serious consideration has been given
to handling the metadata associated with DESCRIPTION by using a repeatable
element simply called DESCRIPTION that contains the metadata content
(or values) associated with an asset. Accompanying the element DESCRIPTION
would be a more refined, qualified element called DESCRIPTION.TYPE that
would identify the type of content that is included in the basic DESCRIPTION
metadata element. Does the Public Broadcasting Community have a preference
for following Dublin Core rules or following our natural instincts?
|
04.01
Description.Abstract
If the PBCore follows the rules
associated with Dublin Core, we can qualify the element DESCRIPTION
by using the more refined DESCRIPTION.ABSTRACT, DESCRIPTION.TABLEOFCONTENTS,
and DESCRIPTION.PROGRAMRELATEDTEXT.
Alternatively, serious consideration has been given
to handling the metadata associated with DESCRIPTION by using a repeatable
element simply called DESCRIPTION that contains the metadata content
(or values) associated with an asset. Accompanying the element DESCRIPTION
would be a more refined, qualified element called DESCRIPTION.TYPE that
would identify the type of content that is included in the basic DESCRIPTION
metadata element. Does the Public Broadcasting Community have a preference
for following Dublin Core rules or following our natural instincts?
|
04.02
Description.TableOfContents
If the PBCore follows the rules
associated with Dublin Core, we can qualify the element DESCRIPTION
by using the more refined DESCRIPTION.ABSTRACT, DESCRIPTION.TABLEOFCONTENTS,
and DESCRIPTION.PROGRAMRELATEDTEXT.
Alternatively, serious consideration has been given
to handling the metadata associated with DESCRIPTION by using a repeatable
element simply called DESCRIPTION that contains the metadata content
(or values) associated with an asset. Accompanying the element DESCRIPTION
would be a more refined, qualified element called DESCRIPTION.TYPE that
would identify the type of content that is included in the basic DESCRIPTION
metadata element. Does the Public Broadcasting Community have a preference
for following Dublin Core rules or following our natural instincts?
|
04.03
Description.ProgramRelatedText
If the PBCore follows the rules
associated with Dublin Core, we can qualify the element DESCRIPTION
by using the more refined DESCRIPTION.ABSTRACT, DESCRIPTION.TABLEOFCONTENTS,
and DESCRIPTION.PROGRAMRELATEDTEXT.
Alternatively, serious consideration has been given
to handling the metadata associated with DESCRIPTION by using a repeatable
element simply called DESCRIPTION that contains the metadata content
(or values) associated with an asset. Accompanying the element DESCRIPTION
would be a more refined, qualified element called DESCRIPTION.TYPE that
would identify the type of content that is included in the basic DESCRIPTION
metadata element. Does the Public Broadcasting Community have a preference
for following Dublin Core rules or following our natural instincts?
DESCRIPTION.PROGRAMRELATEDTEXT is similar to LANGUAGE.USAGE.
Should these two elements be combined?
|
08.00
Type
Currently, the lists of terms
we have found for describing TYPE, TYPE.FORM, and TYPE.GENRE tend to
blur the differences between the three elements. The Public Broadcasting
Core will need to explore and construct well formed lists that match
the element definitions and the needs of the Public Broadcasting communities.
|
08.01
Type.Form
Currently, the lists of terms
we have found for describing TYPE, TYPE.FORM, and TYPE.GENRE tend to
blur the differences between the three elements. The Public Broadcasting
Core will need to explore and construct well formed lists that match
the element definitions and the needs of the Public Broadcasting communities.
|
08.02
Type.Genre
Currently, the lists of terms
we have found for describing TYPE, TYPE.FORM, and TYPE.GENRE tend to
blur the differences between the three elements. The Public Broadcasting
Core will need to explore and construct well formed lists that match
the element definitions and the needs of the Public Broadcasting communities.
|
11.00
Source
[none]
|
13.01
Relation.Type
[none]
|
13.02
Relation.Identifier
[none]
|
14.01
Coverage.Spatial
[none]
|
14.02
Coverage.Temporal
[none]
|
16.01
Audience.Level
[none]
|
16.02
Audience.Rating
[none]
|
| |
02.00
Creator
Like the hierarchy of multiple
Titles that can be associated with an individual resource or asset,
there are levels of Creators who contribute to the existence of a program
or asset. A Creator can be the more encompassing production agency or
producer. A Creator could also be an individual responsible for actually
generating a specific portion of a program or a particular media format
in which the asset is stored or distributed through various play-outs
and pipelines. How confusing will this be to the Public Broadcasting
community? Our current solution was to generate a more refined qualifcation
to the "Creator" element. This accompanying element is called
"Creator.Role" and specifies the role played by the individual
or organization identified under "Creator."
|
02.01
Creator.Role
Like the hierarchy of multipleTitles
that can be associated with an individual resource or asset, there are
levels of Creators who contribute to the existence of a program or asset.
A Creator can be the more encompassing production agency or producer.
A Creator could also be an individual responsible for actually generating
a specific portion of a program or a particular media format in which
the asset is stored or distributed through various play-outs and pipelines.
How confusing will this be to the Public Broadcasting community? Our
current solution was to generate a more refined qualifcation to the
"Creator" element. This accompanying element is called "Creator.Role"
and specifies the role played by the individual or organization identified
under "Creator."
|
05.00
Publisher
[none]
|
05.01
Publisher.Role
[none]
|
06.00
Contributor
[none]
|
06.01
Contributor.Role
[none]
|
15.01
Rights.Usage
Presently, two of the three elements associated
with RIGHTS are expected to store free-text values pertaining to how
organizations can use and reproduce a media item and its related content.
These elements are RIGHTS.USAGE and RIGHTS.REPRODUCTION Public Broadcasting
has some very specific rights issues, including such categories as:
School Rights, Broadcast Rights, Ancilliary Rights, Etc. Further, for
each of the above categories, there are specific types or groupings
that detail the terms of the broader usage and reproduction rights,
including these values: In Perpetuity, From Original Broadcast, From
First Broadcast, Fair Use, Etc. If we don't use a hierarchy of rights
categories to define these potential levels, the alternative is to
combine all values into a rights statement placed into a single metadata
element. An example would be: Broadcast Rights: From First Broadcast:
5 plays in 6 years beginning 01/23/2004 The structure of such a statement,
however, is difficult to standardize. A controlled vocabulary would
need to be implemented in order to create those standards. Various
producing agencies, stations, and distributers would have different
constraints and negotiated limitations to usage and reproduction. Please
share your thoughts.
|
15.02
Rights.Reproduction
(Note: this Unresolved Question is the same
as Survey Question 2.27 for the PBCore Element 15.01: Rights.Usage.
If your comments are the same as your original response for the element
RIGHTS.USAGE, simply type SEE RIGHTS.USAGE COMMENTS in the response
box.) Presently, two of the three elements associated with RIGHTS are
expected to store free-text values pertaining to how organizations
can use and reproduce a media item and its related content. These elements
are RIGHTS.USAGE and RIGHTS.REPRODUCTION Public Broadcasting has some
very specific rights issues, including such categories as: School Rights,
Broadcast Rights, Ancilliary Rights, Etc. Further, for each of the
above categories, there are specific types or groupings that detail
the terms of the broader usage and reproduction rights, including these
values: In Perpetuity, From Original Broadcast, From First Broadcast,
Fair Use, Etc. If we don't use a hierarchy of rights categories to
define these potential levels, the alternative is to combine all values
into a rights statement placed into a single metadata element. An example
would be: Broadcast Rights: From First Broadcast: 5 plays in 6 years
beginning 01/23/2004 The structure of such a statement, however, is
difficult to standardize. A controlled vocabulary would need to be
implemented in order to create those standards. Various producing agencies,
stations, and distributers would have different constraints and negotiated
limitations to usage and reproduction. Please share your thoughts.
|
15.03
Rights.Access
(Note: this Unresolved Question is the same
as Survey Question 2.27 for the PBCore Element 15.01: Rights.Usage.
If your comments are the same as your original response for the element
RIGHTS.USAGE, simply type SEE RIGHTS.USAGE COMMENTS in the response
box.) Presently, two of the three elements associated with RIGHTS are
expected to store free-text values pertaining to how organizations
can use and reproduce a media item and its related content. These elements
are RIGHTS.USAGE and RIGHTS.REPRODUCTION Public Broadcasting has some
very specific rights issues, including such categories as: School Rights,
Broadcast Rights, Ancilliary Rights, Etc. Further, for each of the
above categories, there are specific types or groupings that detail
the terms of the broader usage and reproduction rights, including these
values: In Perpetuity, From Original Broadcast, From First Broadcast,
Fair Use, Etc. If we don't use a hierarchy of rights categories to
define these potential levels, the alternative is to combine all values
into a rights statement placed into a single metadata element. An example
would be: Broadcast Rights: From First Broadcast: 5 plays in 6 years
beginning 01/23/2004 The structure of such a statement, however, is
difficult to standardize. A controlled vocabulary would need to be
implemented in order to create those standards. Various producing agencies,
stations, and distributers would have different constraints and negotiated
limitations to usage and reproduction. Please share your thoughts.
|
07.01
Date.Created
It was determined that an unqualified
element called "Date" made no sense. By its very nature and
the variety of dates that are associated with a resource or asset, a
Date must be qualified or refined with an indication of the meaning
behind a date. Consequently, the PBCore provides only qualified date
elements, including DATE.CREATED, DATE.ISSUED (or aired), DATE.AVAILABLESTART,
DATE.AVAILABLEEND.
An alternative approach would
be to use a repeatable data field called "Date," and associate
it with another data field called "Date.Type" from which the
type of date presented is identified.
|
07.02
Date.Issued
It was determined that an unqualified
element called "Date" made no sense. By its very nature and
the variety of dates that are associated with a resource or asset, a
Date must be qualified or refined with an indication of the meaning
behind a date. Consequently, the PBCore provides only qualified date
elements, including DATE.CREATED, DATE.ISSUED (or aired), DATE.AVAILABLESTART,
DATE.AVAILABLEEND.
An alternative approach would
be to use a repeatable data field called "Date," and associate
it with another data field called "Date.Type" from which the
type of date presented is identified.
|
07.03
Date.AvailableStart
It was determined that an unqualified
element called "Date" made no sense. By its very nature and
the variety of dates that are associated with a resource or asset, a
Date must be qualified or refined with an indication of the meaning
behind a date. Consequently, the PBCore provides only qualified date
elements, including DATE.CREATED, DATE.ISSUED (or aired), DATE.AVAILABLESTART,
DATE.AVAILABLEEND.
An alternative approach would
be to use a repeatable data field called "Date," and associate
it with another data field called "Date.Type" from which the
type of date presented is identified.
|
07.04
Date.AvailableEnd
It was determined that an unqualified
element called "Date" made no sense. By its very nature and
the variety of dates that are associated with a resource or asset, a
Date must be qualified or refined with an indication of the meaning
behind a date. Consequently, the PBCore provides only qualified date
elements, including DATE.CREATED, DATE.ISSUED (or aired), DATE.AVAILABLESTART,
DATE.AVAILABLEEND.
An alternative approach would
be to use a repeatable data field called "Date," and associate
it with another data field called "Date.Type" from which the
type of date presented is identified.
|
09.01
Format.Physical
[none]
|
09.02
Format.Digital
[none]
|
09.03
Format.Identifier
When the PBCore has been tested
against actual media resources and their descriptions in real-world
implementations, it may become evident that the element 09.03 FORMAT.IDENTIFIER
can be merged with the element 10.00 IDENTIFIER.
|
09.04
Format.FileSize
This qualified element maps
to the MPEG-7 descriptor MediaFormat.FileSize.
|
09.05
Format.AudioBitDepth
[none]
|
09.06
Format.AudioChannelConfiguration
[none]
|
09.07
Format.AudioDateRate
[none]
|
09.08
Format.AudioSamplingRate
[none]
|
09.09
Format.ImageAspectRatio
[none]
|
09.10
Format.ImageBitDepth
[none]
|
09.11
Format.ImageChannelConfiguration
[none]
|
09.12
Format.ImageColorCode
[none]
|
09.13
Format.ImageDataRate
[none]
|
09.14
Format.ImageFrameRate
[none]
|
09.15
Format.ImageFrameSize
[none]
|
09.16
Format.TimeStart
The timecode stamp must be annotated in some way in
order to indicate from what source the timecode is obtained, i.e., from
a digital video file or from a videotape machine.
TIMESTART was created as a qualified FORMAT element
for the PBCore. The original Dublin Core has the element called IDENTIFIER.TIMESTAMPS.
The PBCore developers felt more comfortable placing the time stamps
under Format. Do you agree?
|
09.17
Format.Duration
This qualified element maps to the MPEG-7 descriptor
MediaTime.MediaDuration.
The original Dublin Core has the element called FORMAT.EXTENT.
The PBCore developers felt more comfortable placing formulating an element
called FORMAT.DURATION to more closely match broadcasting and media
producer's terminology.
|
09.18
Format.Standard
Given that the PBCore is primarily
designed as an exchange format for media resource information, are we
introducing too much granularity and excessive metadata by having three
separate elements that describe the basic type of media format for an
asset, i.e., FORMAT.STANDARD, FORMAT.TYPE, and FORMAT.ENCODING? Can
we exchange the metadata we need to share with three elements or fewer?
FORMAT.ENCODING is a placeholder element in the PBCore.
If specific types of compressors and encoders are vital to understanding
the nature of a media resource, especially in the rapidly evolving world
of digital media, then should we more carefully define FORMAT.ENCODING
and build controlled vocabularies?
Or should we collapse FORMAT.STANDARD, FORMAT.TYPE
and FORMAT.ENCODING into a single metadata element?
|
09.19
Format.Type
Given that the PBCore is primarily
designed as an exchange format for media resource information, are we
introducing too much granularity and excessive metadata by having three
separate elements that describe the basic type of media format for an
asset, i.e., FORMAT.STANDARD, FORMAT.TYPE, and FORMAT.ENCODING? Can
we exchange the metadata we need to share with three elements or fewer?
FORMAT.ENCODING is a placeholder element in the PBCore.
If specific types of compressors and encoders are vital to understanding
the nature of a media resource, especially in the rapidly evolving world
of digital media, then should we more carefully define FORMAT.ENCODING
and build controlled vocabularies?
Or should we collapse FORMAT.STANDARD, FORMAT.TYPE
and FORMAT.ENCODING into a single metadata element?
|
09.20
Format.Encoding
Given that the PBCore is primarily designed as an exchange
format for media resource information, are we introducing too much granularity
and excessive metadata by having three separate elements that describe
the basic type of media format for an asset, i.e., FORMAT.STANDARD,
FORMAT.TYPE, and FORMAT.ENCODING? Can we exchange the metadata we need
to share with three elements or fewer?
FORMAT.ENCODING is a placeholder element in the PBCore.
If specific types of compressors and encoders are vital to understanding
the nature of a media resource, especially in the rapidly evolving world
of digital media, then should we more carefully define FORMAT.ENCODING
and build controlled vocabularies?
Or should we collapse FORMAT.STANDARD, FORMAT.TYPE
and FORMAT.ENCODING into a single metadata element?
|
10.00
Identifier
When the PBCore has been tested
against actual media resources and their descriptions in real-world
implementations, it may become evident that the element 09.03 FORMAT.IDENTIFIER
can be merged with the element 10.00 IDENTIFIER.
|
12.00
Language
[none]
|
12.01
Language.Usage
Should the element DESCRIPTION.PROGRAMRELATEDTEXT
be combined with LANGUAGE.USAGE?
|
18.00
Annotation
During the development of the
PBCore, there was much discussion about having a single element called
ANNOTATION into which various, additional and unstructured notes about
a media resource could be entered. Many preferred having annotation
exist as a qualifier for all the other PBCore element, e.g., TITLE.ANNOTATION,
DESCRIPTION.ANNOTATION, FORMAT.ANNOTATION, PUBLISHER.ANNOATION, etc.
Opinions?
|
19.00
Location
LOCATION as an Element should be considered
as the Physical Location for physical objects or a File Location (URL,
URI, etc.) for virtual assets. The application of the element LOCATION
may vary between Public Broadcasting stations when used for internal
tracking. The Dictionary Working Group intuitively felt that the use
of LOCATION would also be beneficial as metadata is exchanged between
Public Broadcasting communities. Actual case studies in populating
the element LOCATION with metadata will likely prove useful in helping
define and perfect the meaning and application of this Element. In
particular, LOCATION may solve the problem of how to identify various
manifestations of a media resource through a single metadata record
rather than through multiple, often redundant records. Please share
your thoughts.
|
| LAST |
 |
|
NEXT |
|
| |
