11.1
Sharing, content and metadata exchange
There are several issues with sharing content and metadata. There are privacy issues associated with passing personal information (TS 102 822-3-1 [2]). There are also security issues with exchanging information with others.
TS 102 822-5-1 [7] describes the information on rights management for content and TS 102 822-7 [12] for information on how to protect metadata over bi-directional links.
11.1.1
Content referencing and identification
The current specifications for content referencing describe how to reference a programme (or group of programmes) that can then be eventually resolved to instances of content. In many cases the CRID will refer to content that will be available in the future. This model particularly applies to the broadcast case where a broadcaster assigns and manages the allocation of CRIDs and their resolution.
If the user generates content that is to be shared with others, the user may need to provide an identifier so that others can refer to that content. The TV-Anytime specifications define mechanisms for resolving CRIDs. The user could use these existing mechanisms, that may be provided by a third party. Another alternative is to provide location resolution information as part of the metadata.
There may be a need for identifiers other than the CRID. For example, to identify bit-identical copies of content, for rights purposes and to identify content in particular networks. The metadata specification allows OtherIdentifiers to capture these additional identifiers.
11.1.2 Sharing Metadata
The specifications TS 102 822-3 (all sub-parts) [2], [3], [4] and [5] and TS 102 822-8 [13] cover the transfer of user profile information and metadata. If modifications are made to part of the metadata (e.g. creating a more comprehensive synopsis), the Phase 2 specifications include support for annotating each metadata snippet with specific authorship.
11.1.3
Sharing metadata with content
The specifications do not explicitly cover the binding together of metadata and content.
When content is stored or shared the device will need to store the associated metadata to allow identification later. This is needed because, for lots of broadcast content, the metadata will not be permanently available from a broadcaster's database. This is especially true where the data is delivered via broadcast as the transmitted data is limited by bandwidth constraints. This will probably be also true for online services due to the possibly extremely large volume of data. There are issues with storage of metadata - for instance, the metadata may change (e.g. corrections are made to the synopsis, or metadata such as segmentation information is added). Another issue is the dynamic nature of grouping information - the members of groups will change over time so the stored metadata will not reflect the current status. For example, a particular episode in a long running serial will be identified as a member of the series at the time of
broadcast, but will not be listed several months in the future. So when content is passed around, the metadata may be incomplete or different for instances recorded by different users.
In order to directly associate metadata with content it may be preferable to use a binding format such as AAF or MXF. These formats allow the embedding of metadata with the content and in the case of MXF, is able to map the
TV-Anytime data model to it's own as well as embed XML directly. This will be especially important if the content is
exported to another medium, e.g. onto a recordable DVD.
If the content is created from editing or transcoding another source piece of content, the "DerivedFrom" element could be used to point to the original content and a new CRID could be used.
11.2 Remote programming
One of the key issues with remote programming (TS 102 822-9 [14]) via e-mail is to ensure that only valid e-mails are processed. Without some form of security it would be possible for a third party to remotely control the PDR (denial of service attack).
The PDR could be configured with a list of valid sources and then the "From:" field within the e-mail header could provide a very basic level of checking, but is clearly not sufficient. It would be better if the e-mail body could be signed and/or encrypted in some way.
The security issue is also raised in the exchange of metadata between friends, even if the impact of "recommend" action is more limited than the "record" action.
Annex A (informative):
Example of usage history
The following example highlights the usage history for the "John Smith" user. During the observation period two episodes of the "Fox" series were recorded and subsequently viewed. During the viewing of the "Red Foxes" episode the user zoomed in twice. Finally the user previewed the "Blue Foxes" episode.
<UsageHistory id="usage-history-001" allowCollection="true"> <mpeg7:UserIdentifier protected="true">
<mpeg7:Name xml:lang="en">John Smith</mpeg7:Name> </mpeg7:UserIdentifier>
<mpeg7:UserActionHistory id="useraction-history-001" protected="false"> <mpeg7:ObservationPeriod> <mpeg7:TimePoint>2001-02-02T18:00-08:00</mpeg7:TimePoint> <mpeg7:Duration>PT96H</mpeg7:Duration> </mpeg7:ObservationPeriod> <mpeg7:ObservationPeriod> <mpeg7:TimePoint>2001-02-02T18:00-08:00</mpeg7:TimePoint> <mpeg7:Duration>PT6H</mpeg7:Duration> </mpeg7:ObservationPeriod>
<mpeg7:UserActionList id="ua-list-001" numOfInstances="2" totalDuration="PT2H30M"> <mpeg7:ActionType href="urn:tva:metadata:cs:ActionTypeCS:2004:1.2"> <mpeg7:Name>Record</mpeg7:Name> </mpeg7:ActionType> <mpeg7:UserAction> <mpeg7:ActionTime> <mpeg7:MediaTime> <mpeg7:MediaTimePoint>2001-02-02T19:00:00</mpeg7:MediaTimePoint> <mpeg7:MediaDuration>PT1H</mpeg7:MediaDuration> </mpeg7:MediaTime> </mpeg7:ActionTime>
<mpeg7:ProgramIdentifier organization="TVAF" type="CRID"> crid://broadcaster.com/RedFoxesCrid ForThisEpisode> </mpeg7:ProgramIdentifier> </mpeg7:UserAction> <mpeg7:UserAction> <mpeg7:ActionTime> <mpeg7:MediaTime> <mpeg7:MediaTimePoint>2001-02-03T19:00:00</mpeg7:MediaTimePoint> <mpeg7:MediaDuration>PT1H</mpeg7:MediaDuration> </mpeg7:MediaTime> </mpeg7:ActionTime>
<mpeg7:ProgramIdentifier organization="TVAF" type="CRID"> crid://broadcaster.com/GreyFoxesCrid ForThisEpisode </mpeg7:ProgramIdentifier>
</mpeg7:UserAction> </mpeg7:UserActionList>
<mpeg7:UserActionList id="ua-list-002" numOfInstances="25" totalDuration="PT7H02M"> <mpeg7:ActionType
href="urn:tva:metadata:cs:ActionTypeCS:2004:1.2"> <mpeg7:Name>View</mpeg7:Name>
</mpeg7:ActionType> <mpeg7:UserAction>
<mpeg7:ProgramIdentifier organization="TVAF" type="CRID"> crid://broadcaster.com/RedFoxesCrid ForThisEpisode </mpeg7:ProgramIdentifier> </mpeg7:UserAction> <mpeg7:UserAction> <mpeg7:ActionTime> <mpeg7:MediaTime> <mpeg7:MediaTimePoint>2001-02-04T20:30:00</mpeg7:MediaTimePoint> <mpeg7:MediaDuration>PT1M45S</mpeg7:MediaDuration> </mpeg7:MediaTime> </mpeg7:ActionTime>
<mpeg7:ProgramIdentifier organization="TVAF" type="CRID"> crid://broadcaster.com/GreyFoxesCrid ForThisEpisode </mpeg7:ProgramIdentifier>
</mpeg7:UserAction> </mpeg7:UserActionList>
<mpeg7:UserActionList id="ual-003" numOfInstances="2" totalDuration="PT10S"> <mpeg7:ActionType
<mpeg7:Name>Zoom</mpeg7:Name> </mpeg7:ActionType>
<mpeg7:UserAction>
<mpeg7:ProgramIdentifier organization="TVAF" type="CRID">
crid://broadcaster.com/RedFoxesCrid ForThisEpisode </mpeg7:ProgramIdentifier> </mpeg7:UserAction>
</mpeg7:UserActionList>
<mpeg7:UserActionList id="ual-004" numOfInstances="1"> <mpeg7:ActionType>
<mpeg7:Name>Preview</mpeg7:Name> </mpeg7:ActionType>
<mpeg7:UserAction>
<mpeg7:ProgramIdentifier organization="TVAF" type="CRID"> crid://broadcaster.com/BlueFoxesCrid ForThisEpisode </mpeg7:ProgramIdentifier> </mpeg7:UserAction> </mpeg7:UserActionList> </mpeg7:UserActionHistory> </UsageHistory>