216217 p2p-next d5.3 - europa · 216217 p2p-next d5.3.1d tools for rich metadata and signposts...

P2P-Next D5.3.1d

216217 P2P-NextD5.3.1d

Tools for rich metadata and signposts

Contractual Date of Delivery to the CEC: 31st December 2011Actual Date of Delivery to the CEC: 31st December 2011

Author(s): Michael Eberhard (UNIKLU)Participant(s): Chris Needham (BBC), Daniel Harris (Kendra)

Workpackage: 5Est. person months:

Security: PUNature: P

Version: 1.1Total number of pages: 66

Abstract:This deliverable contains the results from work package 5.3.1 and 5.3.2. The content of thisdeliverable includes the Rich Metadata Specification, which defines the core and optional content-related metadata used within P2P-Next. Furthermore, a description of the Content Collections,which allow to announce the available content using Atom feeds, is provided. Additionally, theContent Discovery mechanism using Rich Metadata is described. For WP5.3.2, a description of thecurrent status of the Signpost development is included in this document. Finally, the XML-/RDF-schemes, examples for the metadata, and the implementation of the Rich Metadata API and KendraSignposts are delivered with this document.

Keyword list: Rich Metadata, Content Collections, Content Discovery, Kendra Signpost

P2P-Next D5.3.1d

Version History

Version Author Description Date0.10 Michael Eberhard Initial Draft 23-07-2008

0.20 Michael Eberhard Added the minimum required attributes,added an example 18-09-2008

0.30 Michael Eberhard Added MPEG-7, URI-Play mapping &examples 17-11-2008

0.31 Michael Eberhard Minor adjustments 28-11-20080.40 Michael Eberhard Added roadmap for signposts 10-12-20080.41 Michael Eberhard Minor adjustments 17-12-2008

0.50 Michael Eberhard

Added the optional metadata to the RichMetadata specification, some changes to thecore attributes due to requirements fromWP5.2

24-07-2009

0.51 Michael Eberhard Minor adjustments, additional examples 06-08-20090.52 Michael Eberhard Adjustments to the scalability metadata 08-09-20090.53 Michael Eberhard Added Signpost status 10-11-2009

0.54 Michael Eberhard Added Content Selection & ChannelMetadata sections, various updates 25-11-2009

0.60 Michael Eberhard Added Search Section, updated URIPlaymapping, various updates 07-12-2009

0.61 Michael Eberhard Minor updates based on the internal review 21-12-20090.70 Michael Eberhard Added Social Metadata, minor updates 30-04-20100.71 Michael Eberhard Minor updates 29-06-2010

0.72 Michael Eberhard Update for live/VoD, replicated feedmetadata of all levels for metadata 31-09-2010

0.80 Michael EberhardUpdate of the core metadata to the finalagreed version that will be supported by allAPIs

09-11-2010

0.90 Michael Eberhard Update of all sections for M36 07-12-20100.91 Michael Eberhard Updates based on the internal review 16-12-20101.0 Michael Eberhard Initial version for M48 07-11-20111.1 Michael Eberhard Final version 19-12-2011

P2P-Next D5.3.1d

Executive Summary

In this document the types of metadata used within NextShare are described. The document containsthe following specifications and descriptions:

The P2P-Next Rich Metadata specification, which allows describing single items like asingle video or one episode of a TV series, as well as the content of TV channels.The Kendra Signpost specification, which provides a concept for content providers to ingesttheir content into the NextShare system supporting various metadata schemes.The Content Collections specification, which describes how these metadata can beannounced for discovery using Atom feeds.A description of the work on content discovery utilizing the P2P-Next Rich Metadataspecification and the Content Collections specification.

The P2P-Next Rich Metadata specification provides a minimum set of attributes which arenecessary to describe a content item in the NextShare system. Additionally, several types of optionalmetadata documents, like payment or advertising metadata, are specified. The main reason forsplitting the metadata in core and optional metadata is that we want to provide the minimummetadata that are required for all business models together with the main torrent file, while theoptional metadata documents should only be provided to the user if they are required by thebusiness model utilized for the content item. To ensure compatibility with as many applications andexisting metadata collections as possible, the attributes of the core and optional specifications of theP2P-Next Rich Metadata specification are mapped to three state-of-the-art metadata standards: TV-Anytime, MPEG-7, and URIPlay. Additionally, the Channel Metadata extensions provide a solutionto describe the programming guide of a TV channel like BBC 1.

The Kendra Signpost specification provides a solution for content providers to ingest their contentcatalogue metadata via an associated public-facing web portal. The Kendra Signpostimplementation enables the translation of content metadata from various providers to variousschemes, including those compatible to the P2P-Next Rich Metadata specification, thus providing aconvenient way for content providers, including recording labels and video distributors, to ingest alltheir content in a NextShare compatible way. The Kendra Signpost Search module also enablesadvanced semantic search of content ingested via the portal and provides a compact and extensibleformat for encoding and distributing search queries and content playlists.

The Content Collections specification describes how the content can be announced to interestedparties utilizing Atom feeds. The specification describes the discovery feeds, which provide anoverview of the available live programs and on-demand collections of a single content provider, andthe content feeds, which provide more details for specific content collections.

The description of the work on content discovery utilizing the P2P-Next Rich Metadataspecification and the Content Collections specification illustrates how the metadata is utilized toallow the user to search for content within the NextShare system.

P2P-Next D5.3.1d

The main changes to the previous version of this deliverable are as follows:Update of the optional payment metadata in the Rich Metadata specification (Section 2.6) toprovide new attributes required by the updated NextShare implementation.The Kendra Signposts documentation (Section 3) has been updated to describe the finalimplementation. In particular, the new integration of NextShare metadata into KendraSignposts is described in Section 3.8.Minor updates to the Content Collections specification (Section 4) reflecting updates to theimplementation.Minor updates to Section 5, describing the final integration of the decentralized searchinterface into NextShare, with the newly added OpenSearch support.The software package section (Section 6) now only contains a description of KendraSignposts, as all other software modules have been been integrated into NextShare and theirusage is described in the referenced deliverables.

P2P-Next D5.3.1d

Table of Contents

1 Introduction..................................................................................................................................8 2 Metadata Definitions....................................................................................................................9

2.1 Use of TV-Anytime...............................................................................................................9 2.2 Use of MPEG-7.....................................................................................................................9 2.3 Use of URIPlay.....................................................................................................................9 2.4 Use of MPEG-21...................................................................................................................9 2.5 Namespace............................................................................................................................9

2.5.1 TV-Anytime Mapping..................................................................................................10 2.5.2 MPEG-7 Mapping.......................................................................................................10 2.5.3 URIPlay Mapping........................................................................................................10 2.5.4 XML Schemes.............................................................................................................10

2.6 Content Description Metadata.............................................................................................11 2.6.1 TV-Anytime Mapping..................................................................................................13 2.6.2 MPEG-7 Mapping.......................................................................................................22 2.6.3 URIPlay Mapping........................................................................................................23

2.7 Channel Description Metadata............................................................................................31 2.7.1 TV-Anytime Mapping..................................................................................................31 2.7.2 MPEG-7 Mappings......................................................................................................31 2.7.3 URIPlay Mappings......................................................................................................32

2.8 Social Metadata...................................................................................................................33 2.8.1 Attribute Mapping........................................................................................................33

3 Kendra Signpost.........................................................................................................................37 3.1 Vocabulary Ingest................................................................................................................38 3.2 Content Ingest.....................................................................................................................39 3.3 Catalogue Mappings............................................................................................................39 3.4 Facet Indexing.....................................................................................................................42 3.5 Inference.............................................................................................................................43 3.6 Query Selection...................................................................................................................44 3.7 Kendra Signpost Output......................................................................................................45 3.8 NextShare Core Integration.................................................................................................46 3.9 Kendra Signpost Modules...................................................................................................51 3.10 Conclusion........................................................................................................................52 3.11 Future Work......................................................................................................................53

4 Content Collections....................................................................................................................54 4.1 Master Discovery Feed........................................................................................................54 4.2 Discovery Feed...................................................................................................................55 4.3 Content Feed.......................................................................................................................57 4.4 Content Feed Namespace....................................................................................................60

5 Content Discovery......................................................................................................................61 6 Software Packages......................................................................................................................64

6.1 Kendra Signpost Implementation........................................................................................64 7 References..................................................................................................................................66

P2P-Next D5.3.1d

Index of FiguresFigure 1: 2-Step-Metadata Creation..................................................................................................8Figure 2: Kendra Signpost Architecture..........................................................................................37Figure 3: Kendra Signpost Mapping creation..................................................................................40Figure 4: Adding a Kendra Signpost Mapping................................................................................40Figure 5: Create Kendra Signpost Mapping Pair.............................................................................41Figure 6: Example Kendra Signpost Mappings...............................................................................41Figure 7: Kendra Signpost Smart Filter Interface............................................................................45Figure 8: Raw output from the headless NextShare Core instance..................................................47Figure 9: Metadata mapping in the NextShare Core Importer.........................................................47Figure 10: NextShare Core Importer results....................................................................................48Figure 11: Processing Archive.org content with the Generic Importer.............................................49Figure 12: Metadata mapping in the Generic Importer....................................................................50Figure 13: Google's Rich Snippets Testing Tool..............................................................................51Figure 14: HTML Search Form......................................................................................................61Figure 15: Search Results of a MetaFeed search.............................................................................62Figure 16: MPEG-7 Description of a BuddyCast Search Result......................................................63Figure 17: Customized Rich Metadata search.................................................................................64

Index of TablesTable 1: Core Attributes..................................................................................................................12Table 2: Optional Attributes............................................................................................................13Table 3: TV-Anytime Mapping for Core Attributes.........................................................................14Table 4: TV-Anytime Extensions for Core Attributes......................................................................14Table 5: TV-Anytime Mapping for Optional Attributes...................................................................16Table 6: TV-Anytime Extensions for Optional Attributes................................................................19Table 7: MPEG-7 Mapping for Core Attributes..............................................................................22Table 8: URIPlay Mapping.............................................................................................................23Table 9: URIplay Mapping for Payment Attributes.........................................................................24Table 10: URIplay Mapping for Advertising Attributes...................................................................24Table 11: Channel Metadata Attributes...........................................................................................31Table 12: TV-Anytime Channel Metadata Mapping........................................................................31Table 13: MPEG-7 Channel Metadata Mapping.............................................................................31Table 14: URIPlay Channel Metadata Mapping..............................................................................32Table 15: Social Metadata Attributes..............................................................................................33Table 16: User Profile Mapping......................................................................................................34Table 17: RDF entity to Kendra Signpost Catalogue Mapping........................................................39Table 18: Kendra Search URL Query Parameters...........................................................................43Table 19: The discovery feed element.............................................................................................54Table 20: The discovery entry element............................................................................................55Table 21: The discovery feed element.............................................................................................56Table 22: The discovery entry element............................................................................................56

P2P-Next D5.3.1d

Table 23: The content feed element................................................................................................57Table 24: The content entry element...............................................................................................58

P2P-Next D5.3.1d

1 IntroductionThe present document contains the P2P-Next Rich Metadata specification, the Signpostspecification, the Content Collections specification, and the description of the work on ContentDiscovery.The P2P-Next Rich Metadata specification aims to provide a set of attributes needed for thedescription of content in peer-to-peer (P2P) environments. For the processing of the metadata wefollow a 2-step metadata creation approach, which starts with the core metadata and allows to addoptional attributes for specific business models in the following step. The process is illustrated inFigure 1:

The current version of the specification addresses both, the core metadata as well as the optionalmetadata. The core metadata contain only those attributes that are essential for all business modelsand that do not change over the course of time. The fact that the core metadata may not change is animportant requirement from WP5.2 [1], as the core metadata is integrated and signed within thetorrent file. Thus, a change of the metadata within the torrent file would make the torrent fileinvalid. Although this makes updates in case of spelling errors difficult, it is essential forprofessional content providers that the metadata describing their content cannot be modified bythird-party users distributing the content.The concept of Kendra Signpost provides a further enhancement for discovery and integration ofrich metadata. The Kendra Signpost implementation provides NextShare content providers withtools to build Kendra Signpost code from their existing data stores and allow the translationbetween various metadata vocabularies including the P2P-Next Rich Metadata specification.The Content Collections specification describes how the available content can be announcedutilizing Atom feeds. The specification contains the description of discovery feeds, which provideinformation about the available live programs and on-demand collections of a single contentprovider, as well as the description of the content feeds, which provide more details for specificcontent collections.

The remainder of this document is structured as follows: In Section 2, the P2P-Next Rich Metadataspecification is described in detailed. Firstly, the core attributes of the metadata specification aredescribed, then the mapping to the three supported standards is defined, and finally an extension for

Figure 1: 2-Step-Metadata Creation

P2P-Next D5.3.1d

the support of channel metadata is proposed. In Section 3, the actual work progress on the KendraSignposts is documented. Section 4 contains the Content Collections specification including thedescription of the discovery and the content feeds. Section 5 provides an overview of the ongoingwork on content discovery utilizing the P2P-Next Rich Metadata as well as the Content Collectionsspecification. Finally, the metadata API and Kendra Signpost implementation delivered togetherwith this document are described in Section 6.

2 Metadata DefinitionsThe P2P-Next Rich Metadata specification aims to provide a minimal set of attributes to describethe content distributed in a P2P system. In this document, we firstly describe which attributes arerequired to describe the content in P2P environments, and than provide mappings of these attributesto the attributes of our three selected metadata standards. The specification describes the mappingsto TV-Anytime [2], MPEG-7 [3] and URIPlay [4] and provides extensions for these approaches tosatisfy the requirements of a P2P environment. For metadata based on TV-Anytime and MPEG-7,the Extensible Markup Language (XML) is used as the representation format. For URIPlay, themetadata is formatted according to URIPlay's ontology specified in the the Resource DescriptionFormat (RDF).

2.1 Use of TV-AnytimeThe TV-Anytime metadata standard provides one mapping for the attributes of the P2P-Next RichMetadata specification. However, some highly relevant attributes for data within P2P environmentscannot be expressed using TV-Anytime only. Thus, this specification provides extensions to theexisting TV-Anytime metadata schemes.

2.2 Use of MPEG-7MPEG-7 is used in two different ways within this specification. Firstly, TV-Anytime uses severalMPEG-7 datatypes and MPEG-7 classification schemes which are described in detail in the MPEG-7 standard. Secondly, MPEG-7 is also used on its own to provide an alternative mapping of therelevant attributes for describing content in P2P environments.

2.3 Use of URIPlayURIPlay [3] provides a third mapping for the P2P-relevant content-related attributes.

2.4 Use of MPEG-21In P2P environments it is essential to describe the fragmentation of P2P data files. Within thisspecification, MPEG-21 Part 17 – Fragment Identification of MPEG Resources [5] is utilized todescribe the fragments of a P2P data file. Furthermore, if scalable bitstreams are distributed throughour P2P system, the scalable layers of the bitstream need to be described. Such a description ofscalable layers is provided by the Adaptation Quality of Service (AQoS) description of MPEG-21Part 7 – Digital Item Adaptation [6].

2.5 NamespaceThe P2P-Next Rich Metadata namespace is defined as:

P2P-Next D5.3.1d

xmlns:p2pnext="urn:p2pnext:metadata:2008"

For the three different mappings of the core attributes, different namespaces need to be utilized.

2.5.1 TV-Anytime MappingFor the TV-Anytime mapping, the P2P-Next Rich Metadata TV-Anytime Mapping XML schemeneeds to be imported into the TV-Anytime metadata scheme:

<import namespace="urn:p2pnext:metadata:2008" schemaLocation="p2p-next_rich_metadata_tva_v0_3.xsd"/>

The P2P-Next Rich Metadata TV-Anytime Mapping XML scheme needs to import the TV-Anytimeand the MPEG-7 XML schemes:

<import namespace="urn:tva:metadata:2007" schemaLocation="tva_metadata_3-1_v141_p2p.xsd"/><import namespace="urn:tva:mpeg7:2005" schemaLocation="tva_mpeg7.xsd"/>

2.5.2 MPEG-7 MappingFor the MPEG-7 mapping, the P2P-Next Rich Metadata MPEG-7 Mapping XML scheme needs tobe imported into the MPEG-7 metadata scheme:

<import namespace="urn:p2pnext:metadata:2008" schemaLocation="p2p-next_rich_metadata_mpeg7_v0_3.xsd"/>

The P2P-Next Rich Metadata TV-Anytime Mapping XML scheme needs to import the MPEG-7XML schemes:

<import namespace="urn:tva:mpeg7:2005" schemaLocation="mpeg7_p2p.xsd"/>

2.5.3 URIPlay MappingFor the URIPlay mapping, the metadata document needs to be formatted according to the URIPlayontologie [4].

2.5.4 XML SchemesAll the XML schemes and RDF ontologies required for the definition of P2P-Next Rich Metadatadocuments accompony this document and are described in the following listing:

tva_metadata_3-1_v141_p2p.xsd: The TV-Anytime scheme which imports the P2P-NextRich Metadata extensions.

p2p-next_rich_metadata_tva_v0_91.xsd: The P2P-Next Rich Metadata scheme whichprovides P2P-relevant extensions for TV-Anytime.

tva_mpeg7.xsd: The XML scheme containing the MPEG-7 types utilized by TV-Anytime.

mpeg7_p2p.xsd: The MPEG-7 scheme which imports the P2P-Next Rich Metadataextensions.

P2P-Next D5.3.1d

p2p-next_rich_metadata_mpeg7_v0_91.xsd: The P2P-Next Rich Metadata scheme whichprovides P2P-relevant extensions for MPEG-7.

xml.xsd: The XML description schemes (DS).

DIA.xsd: The Digital Item Adaptation scheme which is utilized by the scalability metadata.

Uriplay-with-extensions.rdf: The URIPlay ontologie in RDF format including the optionalextensions.

For the TV-Anytime and MPEG-7 mapping, the P2P-Next Rich Metadata documents must be fullynamespace qualified and must declare the P2P-Next Rich Metadata namespace as well as thenamespace of the desired mapping. For the URIPlay mapping, the document needs to be formattedaccording to URIPlay's ontologie.

2.6 Content Description MetadataAs described in Section 1, the P2P-Next Rich Metadata specification consists of the core and theoptional metadata. The core metadata are intended to be provided within the torrent file to be usablefor search, while the optional metadata are provided in separate files and might be distributed aswell through our P2P system, or by alternative means such as a trusted central server in the case ofpayments. To reference the optional metadata to the content and core metadata package, a suitablepackaging solution [1] is utilized. The core metadata attributes, that are essential for all businessmodels and do not change during the lifetime of the content, are described in the table below:

P2P-Next D5.3.1d

Attribute Description

GUID/CRID A unique identification of the content.

Title The title of the file.

Description A description of the file's content.

Provider The user that ingested the file into the P2P system.

Duration The duration of the content in a suitable time unit.

Chapters An indication of the chapters of the content, or noneif the content has no chapters.

Creation Time The time when the content was produced.

Language The language of the content.

Subtitles The language of the subtitles of the content, or noneif there are no subtitles.

Captions The language of the captions of the content, or none ifthere are no captions.

Age Appropriateness The rating in respect of the age appropriateness of thefile.

AV The AV attributes of the file, like the file-format,the bit-rate or the frame-rate of the content, etc.

Originator The original producer of the content.

Genre The genre of the content, e.g., a documentation.

Series/Episode Describes the series and the episode of the content, ifapplicable.

European Content Describes if the content has been produced in Europe.

live/vod Describes if the content is streamed live or as videoon demand

Table 1: Core Attributes

Additionally to the core attributes, the optional attributes are specified to enable a number ofbusiness models and services. These optional metadata attributes are provided separately from thecontent and might change during the lifetime of the content. The optional attributes are grouped anddescribed in the following table.

Please note that the duration is also part of the channel description metadata in Section 2.7.However, the duration is not only important from a scheduling point of view, but also from thecontent point of view, as it might be an additional criteria for selecting a content item forconsumption (i.e., the director's cut is longer than the standard version).

P2P-Next D5.3.1d

Category Attribute Description

Advertising

Target Group Provides information about the targetgroup. Such information include the age,gender, country, etc.

Allow Advertising Specifies if advertising may be providedtogether with the content.

Circular Content Describes if the users are allowed toredistribute the commercial content.

Payment

Payment Identifier A second identifier of the content, as apayment system should not be aware ofthe content for privacy reasons.

Price The price of the content.

Currency The currency for the price.

Payment Recipient The recipient of the payment, if thecontent is not offered for free.

Accept Donations Describes if voluntary donations for theconsumption of the content are accepted.

Amount for Sale Number of items that are for sale

Advanced Information A link to a website with furtherinformation on the payment system.

Scalability

Layer Information Information about the layers of ascalable bitstream.

SPS Information Information about the Sequence ParameterSets (SPS) of the bitstream.

SSPS Information Information about the Subset SPSelements of the bitstream.

PPS Information Information about the Picture ParameterSets (PPS) of the bitstream.

Table 2: Optional Attributes

In the table above, optional attributes for three categories are provided. The attributes provided foradvertising are used to describe properties of the commercial content and how it can be displayedtogether with the actual content. The payment attributes provide the information needed foracquiring a specific content. The attributes provided for scalability are only required for scalablebitstreams and provide the scalable header information to the packetizers and de-packetizers of theP2P system.

These optional attributes provide an initial metadata support for our business models [7], but eachof the categories might be enhanced or additional categories might still be added in the course of theproject. Please note that also additional metadata that are not described in this specification mightvery well be used within our system. Such additional metadata documents are referenced andaccessed using our packaging solution [1].

2.6.1 TV-Anytime MappingThe core attributes were mapped to TV-Anytime as shown in the following table:

P2P-Next D5.3.1d

Attribute TVA Type TVA Attribute

GUID/CRID ProgramInformationType programId

Title BasicContentDescriptionType Title

Description BasicContentDescriptionType Synopsis

Provider TVAMainType publisher

Duration BasicContentDescriptionType Duration

Chapters BasicSegmentDescriptionType

Creation Time BasicContentDescriptionType ProductionDate

Language BasicContentDescriptionType Language

Subtitles BasicContentDescriptionType SignLanguage

Captions BasicContentDescriptionType CaptionLanguage

Age Appropriateness BasicContentDescriptionType ParentalGuidance

AV AVAttributesType

Genre BasicContentDescriptionType Genre

Series/Episode BasicContentDescriptionType Title

European Content BasicContentDescriptionType ProductLocation

Table 3: TV-Anytime Mapping for Core AttributesAs not all of the required attributes can be expressed using TV-Anytime, the P2P-relevant extensionsthat have been designed within P2P-Next are described in this section.

All metadata is structured into self-contained documents. Each document has a single top-levelelement, the TVAMain element, that encloses all other metadata. The structure of such a document isgiven in the TV-Anytime Metadata Standard [2], the P2P-relevant extensions to this standard aredescribed below.

<complexType name="BasicP2PDataDescriptionType"><complexContent>

<extension base="tva:BasicContentDescriptionType"><sequence>

<element name="Originator" type="string" minOccurs="0"/></sequence>

</extension></complexContent>

</complexType>

Name Definition

BasicP2PDataDescriptionType A datatype containing the P2P-relevantextensions of TV-Anytime.

Originator The creator of the content.

Table 4: TV-Anytime Extensions for Core AttributesAn example of a P2P-Next Rich Metadata document utilizing the core attributes provided by TV-Anytime as well as the extensions described above is provided in the following:

<TVAMain xmlns:p2pnext="urn:p2pnext:metadata:2008" xmlns:tva="urn:tva:metadata:2007"xmlns:mpeg7_tva="urn:tva:mpeg7:2005" xmlns:mpeg7="urn:mpeg:mpeg7:schema:2001"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:tva:metadata:2007"xsi:schemaLocation="urn:tva:metadata:2007 tva_metadata_3-1_v141_p2p.xsd" xml:lang="EN"publisher="p2p-next">

P2P-Next D5.3.1d

<CopyrightNotice>Copyright 2010 BBC</CopyrightNotice><ProgramDescription>

<ProgramInformationTable><ProgramInformation programId="crid://p2p-next/example1">

<BasicDescription xsi:type="p2pnext:BasicP2PDataDescriptionType"><Title type="main">Next-Share Test Stream 1</Title><Title type="seriesTitle">The Doe Family</Title><Title type="episodeTitle">John Doe buys a car</Title><Synopsis>

John and Jane Doe visit a car dealer to buy a new car for John</Synopsis><Genre href="urn:mpeg:mpeg7:cs:GenreCS:2001">

<Name>Infotainment</Name></Genre><ParentalGuidance>

<mpeg7_tva:MinimumAge>12</mpeg7_tva:MinimumAge></ParentalGuidance><Language>English</Language><CaptionLanguage>English</CaptionLanguage><SignLanguage>English</SignLanguage><RelatedMaterial>

<HowRelated href="urn:tva:metadata:cs:HowRelatedCS:2007"><Name>Content Package</Name>

</HowRelated><MediaLocator>

<mpeg7_tva:MediaUri>http://p2p-next.org/images/example1.jpg

</mpeg7_tva:MediaUri></MediaLocator>

</RelatedMaterial><ProductionDate>

<TimePoint>2008-07-10T10:00:00+01:00</TimePoint></ProductionDate><ProductionLocation>AT</ProductionLocation><ReleaseInformation>

<ReleaseDate><DayAndYear>2008-07-14</DayAndYear>

</ReleaseDate></ReleaseInformation><Duration>P0Y0M0DT0H0M35S</Duration><p2pnext:Originator>p2p-next</p2pnext:Originator>

</BasicDescription><AVAttributes>

<FileFormat href="urn:mpeg:mpeg7:cs:FileFormatCS:2001"><Name>mp4</Name>

</FileFormat><FileSize>83191350</FileSize><BitRate>524288</BitRate><AudioAttributes>

<Coding href="urn:mpeg:mpeg7:cs:AudioCodingFormatCS:2001"><Name>MPEG-1 Audio Layer III</Name>

</Coding><NumOfChannels>2</NumOfChannels>

</AudioAttributes><VideoAttributes>

<Coding href="urn:mpeg:mpeg7:cs:VisualCodingFormatCS:2001"><Name>MPEG-2 Video Main Profile @ Main Level</Name>

</Coding><HorizontalSize>640</HorizontalSize><VerticalSize>480</VerticalSize><AspectRatio>4:3</AspectRatio><FrameRate>30</FrameRate>

</VideoAttributes></AVAttributes>

</ProgramInformation></ProgramInformationTable>

P2P-Next D5.3.1d

</ProgramDescription></TVAMain>

Furthermore, the optional attributes have been mapped to TV-Anytime as well. For the optionalattributes, TV-Anytime provides only a few attributes that can be reused. The mapping to theseattributes is shown in the table below.

Category Attribute TVA Type TVA Attribute

PaymentPrice PurchaseItemType Price

Currency PriceType Currency

Table 5: TV-Anytime Mapping for Optional Attributes

To support the attributes that cannot be mapped to TV-Anytime, the following extensions areproposed:

<complexType name="P2PTargetGroupType"><sequence>

<element name="Age" type="integer" minOccurs="0" maxOccurs="1"/><element name="Gender" type="string" minOccurs="0" maxOccurs="1"/><element name="Country" type="mpeg7:regionCode" minOccurs="0" maxOccurs="1"/>

</sequence></complexType>

<complexType name="P2PAdvertisementType"><sequence>

<element name="BusinessModel" type="string" minOccurs="0" maxOccurs="unbounded"/><element name="IsLiveContent" type="boolean" minOccurs="0"/><element name="AllowAdvertising" type="boolean" minOccurs="0"/><element name="CircularContent" type="string" minOccurs="0"/><element name="AdType" type="string" minOccurs="0"/><element name="StreamingType" type="string" minOccurs="0"/><element name="AdFormat" type="string" minOccurs="0"/><element name="TargetGroup" type="p2pnext:P2PTargetGroupType" minOccurs="0"/><element name="ContentFormat" type="mpeg7:MediaFormatType" minOccurs="0"/>


<complexType name="PaymentRecipientType"><simpleContent>

<extension base="string"><attribute name="share" type="float" use="optional"/>

</extension></simpleContent>

</complexType>

<complexType name="P2PPurchaseItemType"><complexContent>

<extension base="tva:PurchaseItemType"><sequence>

<element name="PaymentId" type="string" minOccurs="1" maxOccurs="1"/><element name="PaymentRecipient" type="p2pnext:PaymentRecipientType"minOccurs="0"/><element name="AcceptDonations" type="boolean" minOccurs="0" maxOccurs="1"/><element name="AdvancedInfos" type="anyURI" minOccurs="0" maxOccurs="1"/>

</sequence></extension>

</complexContent>

P2P-Next D5.3.1d

</complexType>

<complexType name="SPSType"><sequence>

<element name="spsId" type="integer"/><element name="width" type="integer"/><element name="height" type="integer"/><element name="value" type="base64Binary"/>


<complexType name="PPSType"><sequence>

<element name="spsId" type="integer"/><element name="value" type="base64Binary"/>


<complexType name="P2PScalabilityType"><sequence>

<element name="LayerInfos" type="mpeg21:AdaptationQoSType"/><element name="SPS" type="p2pnext:SPSType" minOccurs="0"maxOccurs="unbounded"/><element name="SSPS" type="p2pnext:SPSType" minOccurs="0"maxOccurs="unbounded"/><element name="PPS" type="p2pnext:PPSType" minOccurs="0"maxOccurs="unbounded"/>


P2P-Next D5.3.1d

Name Definition

P2PTargetGroupType A datatype that defines the attributesneeded for the description of a targetgroup for advertisments.

Age Specifies the age of the target group.

Gender Specifies the gender of the target group.

Country Specifies the country of the target group.

P2PAdvertisementType A datatype containing the attributesrequired to describe advertisements in P2Penvironments.

BusinessModel The business model applied, e.g.,advertising or free-to-view.

IsLiveContent If the content is transmitted live.

AllowAdvertising If advertising is allowed for the content.

CircularContent If the content or parts of it may beredistributed by the users.

AdType The type of the advertisment: Web or STB.

StreamingType The streaming type of the advertisement:In-Stream or Out-Stream.

AdFormat The format of the advertisement, e.g.,banner, pop-up, overlay, etc.

TargetGroup Information about the target group of theadvertisement.

ContentFormat Information about the content format of theadvertisement.

P2PPurchaseItemType A datatype containing the informationneeded for payments in P2P environments.

PaymentId A payment identifier, that is used to hidethe information about the content from thepayment system (for user privacy reasons).

PaymentRecipient Specifies the payment recipient and theshare of the payment the recipientreceives, if multiple recipients arespecified.

AcceptDonations If voluntary donations for the consumptionof the content are accepted.

AdvancedInfos A link to a website where further paymentconditions can be found.

P2PScalabilityType A datatype containing the informationneeded for the distribution of scalablebitstreams in P2P environments.

LayerInfos The information about the scalable layers.This information is provided by means of anAdaptation Quality of Service (AQoS)description as defined in [6].

SPS The Sequence Parameter Sets for thescalable bitstream, encoded in base64.

SSPS The Subset SPS for the scalable bitstream,encoded in base64.

PPS The Picture Parameter Sets for the scalablebitstream, encoded in base64.

P2P-Next D5.3.1d

Table 6: TV-Anytime Extensions for Optional Attributes

Examples for P2P-Next Rich Metadata Documents containing optional attributes are provided inthe following:

<TVAMain xmlns:p2pnext="urn:p2pnext:metadata:2008" xmlns:tva="urn:tva:metadata:2007"xmlns:mpeg7="urn:tva:mpeg7:2005" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:tva:metadata:2007" xsi:schemaLocation="urn:tva:metadata:2007 tva_metadata_3-1_v141_p2p.xsd" xml:lang="EN" publisher="p2p-next">

<ProgramDescription><ProgramInformationTable>

<ProgramInformation programId="crid://p2p-next/example1"><BasicDescription xsi:type="p2pnext:BasicP2PDataDescriptionType">

<p2pnext:AdvertisingData><p2pnext:BusinessModel>BM2</p2pnext:BusinessModel><p2pnext:IsLiveContent>false</p2pnext:IsLiveContent><p2pnext:AllowAdvertising>true</p2pnext:AllowAdvertising><p2pnext:CircularContent>

Allow Superdistribution</p2pnext:CircularContent><p2pnext:AdType>Web</p2pnext:AdType><p2pnext:StreamingType>In-Stream</p2pnext:StreamingType><p2pnext:AdFormat>Banner</p2pnext:AdFormat><p2pnext:TargetGroup>

<p2pnext:Age>30</p2pnext:Age><p2pnext:Gender>W</p2pnext:Gender><p2pnext:Country>AT</p2pnext:Country>

</p2pnext:TargetGroup><p2pnext:ContentFormat>

<VideoAttributes><AspectRatio>16:9</AspectRatio><FrameRate>25</FrameRate>

</VideoAttributes></p2pnext:ContentFormat>

</p2pnext:AdvertisingData></BasicDescription>



<TVAMain xmlns:p2pnext="urn:p2pnext:metadata:2008" xmlns:tva="urn:tva:metadata:2007" xmlns:mpeg7="urn:tva:mpeg7:2005" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:tva:metadata:2007" xsi:schemaLocation="urn:tva:metadata:2007 tva_metadata_3-1_v141_p2p.xsd" xml:lang="EN"publisher="p2p-next">



<PurchaseList><PurchaseItem xsi:type="p2pnext:P2PPurchaseItemType">

<Price currency="EUR">5.0</Price><p2pnext:PaymentId>

test_payment_id</p2pnext:PaymentId><p2pnext:PaymentRecipient share="0.7">

[email protected] </p2pnext:PaymentRecipient><p2pnext:PaymentRecipient share="0.3">

[email protected]</p2pnext:PaymentRecipient><p2pnext:AcceptDonations>

true</p2pnext:AcceptDonations>

P2P-Next D5.3.1d

<p2pnext:AdvancedInfos>http://www.p2p-next.org/paymentInformation.html

</p2pnext:AdvancedInfos></PurchaseItem>

</PurchaseList></BasicDescription>



<TVAMain xmlns:p2pnext="urn:p2pnext:metadata:2008" xmlns:tva="urn:tva:metadata:2007"xmlns:mpeg7="urn:tva:mpeg7:2005" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:tva:metadata:2007" xmlns:mpeg21="urn:mpeg:mpeg21:2003:01-DIA-NS"xsi:schemaLocation="urn:tva:metadata:2007 tva_metadata_3-1_v141_p2p.xsd" xml:lang="EN"publisher="p2p-next">



<p2pnext:ScalabilityData><p2pnext:LayerInfos xmlns="urn:mpeg:mpeg21:2003:01-DIA-NS">

<Module xsi:type="UtilityFunctionType"><Constraint iOPinRef="Bitrate">

<Values xsi:type="IntegerVectorType"><Vector>400 800 1200 2400</Vector>

</Values></Constraint><AdaptationOperator iOPinRef="QualityLevel">


</Values></AdaptationOperator><AdaptationOperator iOPinRef="DependencyId">


</Values></AdaptationOperator><AdaptationOperator iOPinRef="TemporalLevel">


</Values></AdaptationOperator><Utility iOPinRef="Framerate">


</Values></Utility><Utility iOPinRef="Width">


</Values></Utility><Utility iOPinRef="Height">


</Values></Utility>

</Module></p2pnext:LayerInfos><p2pnext:SPS>

<p2pnext:spsId>1</p2pnext:spsId><p2pnext:width>320</p2pnext:width><p2pnext:height>240</p2pnext:height><p2pnext:value>Z1MADUsBBrLCwSyA</p2pnext:value>

</p2pnext:SPS>

P2P-Next D5.3.1d

<p2pnext:SPS><p2pnext:spsId>2</p2pnext:spsId><p2pnext:width>640</p2pnext:width><p2pnext:height>480</p2pnext:height><p2pnext:value>Z02AR7rsFiaq</p2pnext:value>

</p2pnext:SPS><p2pnext:PPS>

<p2pnext:spsId>1</p2pnext:spsId><p2pnext:value>aEngRqA=</p2pnext:value>

</p2pnext:PPS><p2pnext:PPS>

<p2pnext:spsId>2</p2pnext:spsId><p2pnext:value>an4EagrA</p2pnext:value>

</p2pnext:PPS></p2pnext:ScalabilityData>

</BasicDescription></ProgramInformation>

</ProgramInformationTable></ProgramDescription>

</TVAMain>

P2P-Next D5.3.1d

2.6.2 MPEG-7 MappingThe attributes were mapped to MPEG-7 as shown in the following table:

Attribute MPEG-7 Type MPEG-7 Attribute

GUID/CRID MediaDescriptionType EntityIdentifier

Title CreationType Title

Description CreationType Abstract

Provider CreationType Creator

Duration UsageDescriptionType Duration

Chapters VideoSegmentType

Creation Time CreationType CreationCoordinates

Language ClassificationType Language

Subtitles ClassificationType SignLanguage

Captions ClassificationType CaptionLanguage

Age Appropriateness ClassificationType ParentalGuidance

AV MediaProfileType

Originator CreationType Creator

Genre ClassificationType Genre

Series/Episode CreationType Title

European Content CreationType CreationCoordinates

live/vod UsageDescriptionType AvailabilityPeriod

Table 7: MPEG-7 Mapping for Core AttributesAn example of a P2P-Next Rich Metadata document utilizing the core attributes provided byMPEG-7 as well as the extensions described above is very similar to the TV-Anytime exampleprovided in Section 2.6.1 and is provided with this deliverable.

The optional metadata attributes have been integrated into MPEG-7 very similar to TV-Anytime.The advertisement and scalability metadata are integrated into MPEG-7 as described in Section2.6.1, the integration of the payment metadata is performed as follows:

<complexType name="PriceType"><simpleContent>

<extension base="float"><attribute name="currency" type="mpeg7:currencyCode" use="required"/>

</extension></simpleContent>

</complexType>

<complexType name="P2PPurchaseItemType"><sequence>

<element name="PaymentId" type="string" minOccurs="1" maxOccurs="1"/><element name="PaymentRecipient" type="p2pnext:PaymentRecipientType" minOccurs="0"maxOccurs="unbounded"/><element name="Price" type="p2pnext:PriceType" minOccurs="1" maxOccurs="1"/><element name="AcceptDonations" type="boolean" minOccurs="0"maxOccurs="1"/><element name="AdvancedInfos" type="anyURI" minOccurs="0"maxOccurs="unbounded"/>

P2P-Next D5.3.1d


The attributes are used in the P2P-Next system as described in Section 2.6.1.

2.6.3 URIPlay MappingThe core attributes were mapped to URIPlay as shown in the following table:

Attribute RDF Class RDF Predicate

Title po:Brand/po:Episode dc:title/play:seasonTitle

Series/Episode po:Episode play:seasonPosition/po:position

Description po:Episode dc:description

Provider play:Location play:provider

Originator play:Location play:origniator

Copyright Owner po:Episode dcterms:rightsHolder

Thumbnail po:Episode play:image

User Rating play:Location play:quality

Duration play:Version po:duration

Language po:Version play:audioLanguage

Subtitle po:Version po:subtitle_language

Captions po:Version play:captionLanguage

Age Appropriateness po:Version play:guidance

AV po:Version play:manifestedAs

Policy play:Location play:restrictedBy

Genre po:Episode po:genre

Is it live play:Location play:transportIsLive

Authentication play:Policy play:authenticationMethod

GUID/CRID play:Location play:uri

European Content play:Episode dcterms:spatial

Segmentation po:Version dcterms:hasPart

Contains Commercial Content po:Version play:containsAdvertising

Ingest Time play:Location dcterms:dateSubmitted

Creation Time play:Location dcterms:created

Table 8: URIPlay MappingMany of these attributes were already supported by the URIplay vocabulary and by other well usedRDF vocabularies. URIplay was extended to cover the provider, originator, and authenticationattributes.

Optional P2PNext metadata attributes were found to match well with the existing URIplayvocabulary.

It was possible to map P2PNext payment attributes to URIplay as follows:

P2P-Next D5.3.1d

Category Attribute RDF Class RDF Predicate

Payment

Price play:Policy play:price

Currency play:Policy play:currency

Payment Identifier play:Location owl:sameAs

Accept Donations play:Policy play:revenueModel

Advanced Information play:Policy rdfs:seeAlso

Table 9: URIplay Mapping for Payment Attributes

P2PNext advertising attributes were not fully supported by URIplay. A small number of attributesmap to the existing vocabulary:

Category Attribute RDF Class RDF Predicate

AdvertisingBusiness Model play:Policy play:revenueModel

Is Live Content play:Location play:transportIsLive

Table 10: URIplay Mapping for Advertising Attributes

Other advertising attributes have been proposed for addition to URIplay via the followingextension, as additions to existing Item, Location, and Policy classes:

<owl:ObjectProperty rdf:about="adItem"> <rdfs:comment>An Item that forms an advertisement to potentially be included during playback of this Location</rdfs:comment> <rdfs:range rdf:resource="Item"/> <rdfs:domain rdf:resource="Location"/>

<vs:term_status>testing</vs:term_status></owl:ObjectProperty>

<owl:DatatypeProperty rdf:about="adFormat"><vs:term_status>testing</vs:term_status>

<rdfs:domain rdf:resource="Policy"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:comment>The format of advertising for this Location, e.g., (for video) pre-roll, post-roll, mid-roll and (for mixed media) banner, pop-up, overlay. Note: we are still investigating how to best use this predicate. A defined vocabulary of options may be provide later.</rdfs:comment></owl:DatatypeProperty>

<owl:DatatypeProperty rdf:about="targetAge"><vs:term_status>testing</vs:term_status>

<rdfs:domain rdf:resource="Item"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:comment>A target age group for this content. Of particular use when applied to advertising messages, or items containing advertising messages.</rdfs:comment></owl:DatatypeProperty>

<owl:DatatypeProperty rdf:about="targetGender"><vs:term_status>testing</vs:term_status>

<rdfs:domain rdf:resource="Version"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:subPropertyOf rdf:resource="http://xmlns.com/foaf/spec/#term_gender" /> <rdfs:comment>A target gender for this content. Of particular use when applied to advertising messages, or items containing advertising messages.</rdfs:comment></owl:DatatypeProperty>

<owl:DatatypeProperty rdf:about="targetCountry"><vs:term_status>testing</vs:term_status>

<rdfs:domain rdf:resource="Version"/>

P2P-Next D5.3.1d

<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:comment>A target country for this content. Of particular use when applied to advertising messages</rdfs:comment></owl:DatatypeProperty>

<owl:FunctionalProperty rdf:about="targetDevice"><vs:term_status>testing</vs:term_status>

<rdfs:domain rdf:resource="Version"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#DatatypeProperty"/> <rdfs:comment>The type of device this content is intended for (PC, big-screen TV, or mobile). This is of particular use where the content is an advertisement. Some advertisers wish to target particular types of devices for their messages.</rdfs:comment> <rdfs:range> <owl:DataRange> <owl:oneOf rdf:parseType="Resource"> <rdf:first>PC</rdf:first> <rdf:rest rdf:parseType="Resource"> <rdf:first>TV</rdf:first> <rdf:rest rdf:parseType="Resource"> <rdf:first>mobile</rdf:first> <rdf:rest rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil"/> </rdf:rest> </rdf:rest> </owl:oneOf> </owl:DataRange> </rdfs:range></owl:FunctionalProperty>

<owl:FunctionalProperty rdf:about="isRedistributable"><vs:term_status>testing</vs:term_status>

<rdfs:domain rdf:resource="Version"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#boolean"/> <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#DatatypeProperty"/> <rdfs:comment>Can a user redistribute this content? Of particular relevance to advertising content.</rdfs:comment></owl:FunctionalProperty>

<owl:FunctionalProperty rdf:about="advertisingAllowed"><vs:term_status>testing</vs:term_status>

<rdfs:domain rdf:resource="Policy"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#boolean"/> <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#DatatypeProperty"/> <rdfs:comment> Can a party other than the content owner add advertising to this content? </rdfs:comment></owl:FunctionalProperty>

Note that in the case of out-of-stream advertising a reference will be provided from the contentLocation to the advertising Item via the predicate play:adItem, thus reusing much of the existingURIplay model for advertising content.

URIplay does not currently describe Scaleable Video Coding, but this concept is a close match tothe URIplay Encoding class. A simple extension has been proposed that follows a similar structureto the P2PNext SVC extensions:

<owl:FunctionalProperty rdf:about="svcBitRates"><vs:term_status>testing</vs:term_status>

<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="Encoding"/> <rdfs:comment> A vector describing the bit rate of Scalable Video Coding (SVC) layers

P2P-Next D5.3.1d

</rdfs:comment></owl:FunctionalProperty>

<owl:FunctionalProperty rdf:about="svcQualityLevels"><vs:term_status>testing</vs:term_status>

<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="Encoding"/> <rdfs:comment>A vector describing the quality level of Scalable Video Coding (SVC) layers</rdfs:comment></owl:FunctionalProperty>

<owl:FunctionalProperty rdf:about="svcDependencyIds"><vs:term_status>testing</vs:term_status>

<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="Encoding"/> <rdfs:comment>A vector describing the dependencies of Scalable Video Coding (SVC) layers</rdfs:comment></owl:FunctionalProperty>

<owl:FunctionalProperty rdf:about="svcTemporalLevels"><vs:term_status>testing</vs:term_status>

<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="Encoding"/> <rdfs:comment>A vector describing the temporal levels of Scalable Video Coding (SVC) layers</rdfs:comment></owl:FunctionalProperty>

<owl:FunctionalProperty rdf:about="svcFrameRates"><vs:term_status>testing</vs:term_status>

<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="Encoding"/> <rdfs:comment>A vector describing the frame rates of Scalable Video Coding (SVC) layers</rdfs:comment></owl:FunctionalProperty>

<owl:FunctionalProperty rdf:about="svcWidths"><vs:term_status>testing</vs:term_status>

<rdfs:domain rdf:resource="Encoding"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:comment>A vector describing the frame width of Scalable Video Coding (SVC) layers</rdfs:comment></owl:FunctionalProperty>

<owl:FunctionalProperty rdf:about="svcHeights"><vs:term_status>testing</vs:term_status>

<rdfs:domain rdf:resource="Encoding"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:comment>A vector describing the frame height of Scalable Video Coding (SVC) layers</rdfs:comment></owl:FunctionalProperty>

<owl:Class rdf:about="SvcParameterSet"><vs:term_status>testing</vs:term_status>

<rdfs:comment>A Scalable Video Coding (SVC) Parameter Set.</rdfs:comment></owl:Class>

<owl:Class rdf:about="SvcSequenceParameterSet"><vs:term_status>testing</vs:term_status>

<rdfs:comment>A Scalable Video Coding (SVC) Sequence Parameter Set.</rdfs:comment> <rdfs:subClassOf rdf:resource="http://uriplay.org/elements/SvcParamterSet"/></owl:Class>

<owl:Class rdf:about="SvcPictureParameterSet"><vs:term_status>testing</vs:term_status>

<rdfs:comment>A Scalable Video Coding (SVC) Picture Parameter Set.</rdfs:comment> <rdfs:subClassOf rdf:resource="http://uriplay.org/elements/SvcParamterSet"/>

P2P-Next D5.3.1d

</owl:Class>

<owl:ObjectProperty rdf:about="usesParameterSet"> <rdfs:comment>Link to a Scalable Video Coding (SVC) Paramter Set used in this encoding (either a Sequence Parameter Set or a Picture Parameter Set)</rdfs:comment> <rdfs:range rdf:resource="SvcParameterSet"/> <rdfs:domain rdf:resource="Encoding"/>

<vs:term_status>testing</vs:term_status></owl:ObjectProperty>

<owl:DatatypeProperty rdf:about="svcParameterSetHeight"><vs:term_status>testing</vs:term_status>

<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="ParameterSet"/> <rdfs:comment> Height applied to a Scalable Video Coding (SVC) ParameterSet </rdfs:comment></owl:DatatypeProperty>

<owl:DatatypeProperty rdf:about="svcParameterSetWidth"><vs:term_status>testing</vs:term_status>

<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="ParameterSet"/> <rdfs:comment> Width applied to a Scalable Video Coding (SVC) ParameterSet </rdfs:comment></owl:DatatypeProperty>

<owl:DatatypeProperty rdf:about="svcParameterSetValue"><vs:term_status>testing</vs:term_status>

<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="ParameterSet"/> <rdfs:comment> Value (base-64 encoded) of a Scalable Video Coding (SVC) ParameterSet </rdfs:comment></owl:DatatypeProperty>

<owl:DatatypeProperty rdf:about="metaDataSourceStatement">

<vs:term_status>unstable</vs:term_status> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:comment> A statement required by the providers or distributors of the metadata </rdfs:comment></owl:DatatypeProperty><owl:DatatypeProperty rdf:about="metaDataLicence">

<vs:term_status>unstable</vs:term_status> <owl:versionInfo> TODO: This should be taken from an existing licence ontology </owl:versionInfo> <rdfs:comment>The licence that applies to the metadata in this instance</rdfs:comment> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:subPropertyOf rdf:resource="http://purl.org/dc/terms/license" /></owl:DatatypeProperty><owl:DatatypeProperty rdf:about="metaDataSource">

<vs:term_status>unstable</vs:term_status> <rdfs:comment>The source of the metadata in this instance</rdfs:comment> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <owl:versionInfo>TODO: URI type</owl:versionInfo></owl:DatatypeProperty>

An example of a P2P-Next Rich Metadata Document containing optional attributes is providedbelow:

P2P-Next D5.3.1d

<po:Episode rdf:about="http://open.bbc.co.uk/rad/uriplay/content/p2pexample/s01e01"> <dc:title>Example content...</dc:title> <play:seasonTitle>The First Season</play:seasonTitle> <dc:description> ...with an example description of the contained content </dc:description> <po:position>1</po:position> <play:seasonPosition>1</play:seasonPosition> <dcterms:rightsHolder rdf:resource="http://www.bbc.co.uk/"/> <play:image rdf:resource="http://open.bbc.co.uk/rad/p2p-next/test-content.jpeg"/> <po:genre rdf:resource="http://www.bbc.co.uk/programmes/genres/news"/> <po:genre rdf:resource="http://www.bbc.co.uk/programmes/genres/sport"/> <dcterms:spatial>UK</dcterms:spatial> <po:Version rdf:about="http://open.bbc.co.uk/rad/uriplay/content/p2pexample/s01e01/main"> <play:audioLanguage>ENG</play:audioLanguage> <play:captionLanguage>ENG</play:captionLanguage> <po:subtitle_language>ENG</po:subtitle_language> <play:guidance rdf:resource="http://open.bbc.co.uk/rad/guidance/adult-humour"/> <play:guidance rdf:resource="http://open.bbc.co.uk/rad/guidance/disturbing-scenes"/> <po:duration>600</po:duration> <dcterms:hasPart rdf:resource="http://www.bbc.co.uk/content/p2pexample/s01e01/segment-1"/> <play:manifestedAs> <play:Encoding rdf:about="http://open.bbc.co.uk/rad/uriplay/content/p2pexample/s01e01/main/h264">  <play:availableAt>  <play:Location rdf:about="http://open.bbc.co.uk/rad/uriplay/content/p2pexample/s01e01/main/avi /p2pnext-payment">  <play:restrictedBy rdf:resource="http://open.bbc.co.uk/rad/uriplay/policy/p2pnext-payment"/> <play:uri rdf:resource="http://open.bbc.co.uk/rad/p2pnext/test-content-a.mv4"/> <play:provider rdf:resource="http://www.bbc.co.uk/"/> <play:origniator rdf:resource="http://www.theguardian.co.uk/"/> <play:quality>8</play:quality> <play:transportIsLive>true</play:transportIsLive> <dcterms:dateSubmitted>2008-08-20T02:14:22Z</dcterms:dateSubmitted> <dcterms:created>2008-08-20T01:19:42Z</dcterms:created> </play:Location> </play:availableAt> <play:availableAt>  <play:Location rdf:about="http://open.bbc.co.uk/rad/uriplay/content/p2pexample/s01e01/main/avi /p2pnext-donation"> <play:restrictedBy rdf:resource="http://open.bbc.co.uk/rad/uriplay/policy/p2pnext-donation"/> <play:uri rdf:resource="http://open.bbc.co.uk/rad/p2pnext/test-content-a.mpeg"/> <play:provider rdf:resource="http://adrideo.com/"/> <play:origniator rdf:resource="http://dexy.com/"/> <play:quality>8</play:quality> <play:transportIsLive>true</play:transportIsLive> <dcterms:dateSubmitted>2008-08-20T02:14:22Z</dcterms:dateSubmitted> <dcterms:created>2008-08-20T01:19:42Z</dcterms:created> </play:Location> </play:availableAt> </play:Encoding> </play:manifestedAs>

P2P-Next D5.3.1d

<play:manifestedAs>  <play:Encoding rdf:about="http://open.bbc.co.uk/rad/uriplay/content/p2pexample/s01e01/main/ h264-svc"> <play:svcBitRates>400 800 1200 2400</play:svcBitRates> <play:svcQualityLevels>0 1 0 1</play:svcQualityLevels> <play:svcDependencyIds>0 0 1 1</play:svcDependencyIds> <play:svcTemporalLevels>0 0 0 0</play:svcTemporalLevels> <play:svcFrameRates>25 25 25 25</play:svcFrameRates> <play:svcWidths>320 320 640 640</play:svcWidths> <play:svcHeights>240 240 480 480</play:svcHeights> <play:usesParameterSet> <play:SvcSequenceParameterSet> <play:svcParameterSetHeight>320</play:svcParameterSetHeight> <play:svcParameterSetWidth>240</play:svcParameterSetWidth> <play:svcValue>Z1MADUsBBrLCwSyA</play:svcValue> </play:SvcSequenceParameterSet> </play:usesParameterSet> <play:usesParameterSet> <play:SvcSequenceParameterSet> <play:svcParameterSetHeight>640</play:svcParameterSetHeight> <play:svcParameterSetWidth>480</play:svcParameterSetWidth> <play:svcParameterSetValue>Z02AR7rsFiaq</play:svcParameterSetValue> </play:SvcSequenceParameterSet> </play:usesParameterSet> <play:usesParameterSet> <play:SvcPictureParameterSet> <play:svcParameterSetHeight>320</play:svcParameterSetHeight> <play:svcParameterSetWidth>240</play:svcParameterSetWidth> <play:svcParameterSetValue>aEngRqA=</play:svcParameterSetValue> </play:SvcPictureParameterSet> </play:usesParameterSet> <play:availableAt> <play:Location rdf:about="http://open.bbc.co.uk/rad/uriplay/content/p2pexample/s01e01/main/ h264-svc/p2pnext"> <play:uri rdf:resource="http://open.bbc.co.uk/rad/p2pnext/test-content-a-svc.mpeg"/> </play:Location> </play:availableAt> </play:manifestedAs> </po:Version> <po:version>  <po:Version rdf:about="http://open.bbc.co.uk/rad/uriplay/content/p2pexample/s01e01/with-ads">  <play:containsAdvertisng>true</play:containsAdvertisng> <play:isRedistributable>true</play:isRedistributable> <play:targetDevice>PC</play:targetDevice> <play:targetAge>30</play:targetAge> <play:targetGender>female</play:targetGender> <play:targetCountry>AT</play:targetCountry> <po:duration>600</po:duration> <play:manifestedAs> <play:Encoding rdf:about="http://open.bbc.co.uk/rad/uriplay/content/p2pexample/s01e01/ with-ads/h264">  <play:availableAt>  <play:Location rdf:about="http://open.bbc.co.uk/rad/uriplay/content/p2pexample/s01e01/ with-ads/h264/p2pnext">

P2P-Next D5.3.1d

<play:restrictedBy rdf:resource="http://open.bbc.co.uk/rad/uriplay/policy/p2pnext-advertising"/> <play:uri rdf:resource="http://open.bbc.co.uk/rad/p2pnext/ test-content-a-with-ads.mpeg"/> </play:Location> </play:availableAt> </play:Encoding> </po:Version></po:Episode>

<play:Policy rdf:about="http://open.bbc.co.uk/rad/uriplay/policy/p2pnext-advertising"/>

<play:revenueModel>free to view</play:revenueModel><play:adFormat>banner</play:adFormat>

</play:Policy>

<play:Policy rdf:about="http://open.bbc.co.uk/rad/uriplay/policy/p2pnext-payment"/>

<play:revenueModel>pay to buy</play:revenueModel><play:price>5.0</play:price><play:currency>EUR</play:price><rdfs:seeAlso>http://www.p2p-next.org/paymentInformation.html</rdfs:seeAlso>

</play:Policy>

<play:Policy rdf:about="http://open.bbc.co.uk/rad/uriplay/policy/p2pnext-donation"/>

<play:revenueModel>voluntary donation</play:revenueModel><rdfs:seeAlso>http://www.p2p-next.org/donationInformation.html</rdfs:seeAlso>

</play:Policy>

P2P-Next D5.3.1d

2.7 Channel Description MetadataAdditionally to the content description metadata described in detail in the previous section, channeldescription metadata is required in order to describe all the content items of a specific channel (e.g.,for an EPG-like application). As the description of single items of a channel is already provided inSection 2.6, the addition of the scheduling metadata achieves a full solution for channel descriptionmetadata. The channel description metadata need to provide the following attributes:


GUID/CRID An identifier matching the scheduling information tothe already available content information defined insection 2.6.

Start Time The start time of the content item.

Duration The duration of the content item.

Transmission Type If the content is transmitted live

Table 11: Channel Metadata Attributes

2.7.1 TV-Anytime MappingThe scheduling is expressed in TV-Anytime by the ScheduleEvent type and its attributes asspecified in the following table:

Attribute TVA Type TVA Attribute

GUID/CRID Program crid

Start Time PublishedStartTime

Duration PublishedDuration

Live Live

Table 12: TV-Anytime Channel Metadata Mapping

Based on this mapping, an example for such a TV-Anytime scheduling event would look as follows:<ScheduleEvent> <Program crid="crid://p2p-next/example1"/> <PublishedStartTime>2010-11-10T21:45:00Z</PublishedStartTime> <PublishedDuration>PT01H15M00S</PublishedDuration>

<Live value="true"/></ScheduleEvent>

2.7.2 MPEG-7 MappingsIn MPEG-7, the scheduling is expressed utilizing the MediaTimeType as illustrated in the followingtable:

Attribute MPEG7 Type MPEG7 Attribute

GUID/CRID MediaLocator MediaURI

Start Time MediaTimePoint

Duration MediaDuration

Live AvailabilityPeriod Type

Table 13: MPEG-7 Channel Metadata Mapping

P2P-Next D5.3.1d

An example of such an MPEG-7 document is given below:<Availability>

<InstanceRef href="crid://p2p-next/example1"/> <AvailabilityPeriod type="live">

<TimePoint>2010-10-08T12:00:00+00:00</TimePoint> <Duration>PT30M</Duration>

</AvailabilityPeriod> </Availability>

2.7.3 URIPlay MappingsIn URIPlay, the scheduling is expressed utilizing the BroadcastType as illustrated in the followingtable:

Attribute URIPlay Type URIPlay Attribute

GUID/CRID play:Broadcast play:uri

Start Time play:Broadcast play:start

Duration play:Broadcast play:BroadcastDuration

Table 14: URIPlay Channel Metadata Mapping

P2P-Next D5.3.1d

2.8 Social Metadata

To provide information about the users of the NextShare system and allow those users to rate theaccessed content, social metadata are required. As the social metadata are not directly related tospecific content items the social metadata are distributed independently. Currently, two types ofsocial metadata are supported. The user profile metadata provide detailed information about theuser and are used for displaying the social profile and to relate content to its provider. The mediareview metadata are utilized to allow users to rate the content accessed through the NextSharesystem. The attributes required for the social metadata are described in the following table.

User Profile

General User Information Attributes like name, title, sex,birthday, etc.

Location Information Attributes addressing the currentlocation, the home address, possibleprevious addresses...

Contact Information Contact information like phone, mailaddress, instant messenger ID, …

Relations Description of relations to familiymembers, life partners, etc.

Education & Work Information about attended educationalinstitutions and current/formeremployers

Interests Information about favorite activities,movies, music, etc.

Media Review

Indivdual Review Desribing the rating of the content interms of content rating (the quality ofthe content itself), quality rating (thequality of audio and video), andidentity rating (is the contentidentical to its description).

Aggregated Review Describes the average of all availableuser reviews.

Table 15: Social Metadata Attributes

2.8.1 Attribute MappingAs social metadata are not defined by TV-Anytime, MPEG-7, or URIPlay, the attribute mappingswere created once and can be utilized to extend all three standards. For the user profile metadata,the MPEG-21 DIA UserInfo type was extended. For the media review rating, a new type wasproposed for MPEG-7. The user profile attribute mappings are illustrated in the following table:

P2P-Next D5.3.1d

Attribute MPEG-21 Attribute

Username dia:UserInfo[@xsi:type="PersonType"]/Name[@type="variant"]/GivenName

Firstname dia:UserInfo[@xsi:type="PersonType"]/Name/GivenName

Lastname dia:UserInfo[@xsi:type="PersonType"]/Name/FamilyName

Title dia:UserInfo[@xsi:type="PersonType"]/Name/Title

Birthday dia:UserInfo[@xsi:type="PersonType"]/Name/@dateFrom

Profile Picture dia:UserInfo[@xsi:type="PersonType"]/Icon

Current Location dia:Destination/Location

Current Time dia:Destination/Time

Home Address dia:UserInfo[@xsi:type="PersonType"]/Address

Home Zipcode dia:UserInfo[@xsi:type="PersonType"]/Address/PostalAddress/PostingIdentifier

Home Country dia:UserInfo[@xsi:type="PersonType"]/Address/Region

Home Semantic Description dia:UserInfo[@xsi:type="PersonType]/Address/NameTerm

Home Geographic Position dia:UserInfo[@xsi:type="PersonType"]/Address/GeographicPosition

Email dia:UserInfo[@xsi:type="PersonType"]/ElectronicAddress/Email

Phone dia:UserInfo[@xsi:type="PersonType"]/ElectronicAddress/Telephone

Fax dia:UserInfo[@xsi:type="PersonType"]/ElectronicAddress/Fax

Link dia:UserInfo[@xsi:type="PersonType"]/ElectronicAddress/Url

Table 16: User Profile Mapping

Additionally, the following extension to the UserInfo type are proposed:

<complexType name="UserProfileType"><complexContent>

<extension base="mpeg7:PersonType"><sequence>

<element name="PublicIdentifier" type="mpeg7:UniqueIDType"/><element name="Description" type="mpeg7:TextAnnotationType" minOccurs="0"/><element name="TimeZone" type="up:TimeZoneType" minOccurs="0"/><element name="PrimaryLanguage" type="language" minOccurs="0"/><element name="Relations" type="up:RelationsType" minOccurs="0"/><element name="PersonalInterests" type="up:PersonalInterestsType"

minOccurs="0"/></sequence><attribute name="sex">

<simpleType><restriction base="string">

<enumeration value="male"/><enumeration value="female"/>

</restriction></simpleType>

</attribute></extension>

</complexContent></complexType>

<complexType name="TimeZoneType"><attribute name="value">

P2P-Next D5.3.1d

<simpleType><restriction base="string">

<pattern value="Z|((\-|\+)\d{2}:\d{2})"/></restriction>

</simpleType></attribute>

</complexType><complexType name="RelationsType">

<sequence><element name="Affiliation" type="up:AffiliationType" minOccurs="0"

maxOccurs="unbounded"/><element name="Friend" type="up:FriendType" minOccurs="0" maxOccurs="unbounded"/>


<complexType name="RelationBaseType" abstract="true"><complexContent>

<extension base="mpeg7:DSType"><sequence>

<element name="Role" type="mpeg7:ControlledTermUseType"/></sequence><attribute name="dateFrom" type="mpeg7:timePointType"/><attribute name="dateTo" type="mpeg7:timePointType"/>


</complexType>

<complexType name="AffiliationType"><complexContent>

<extension base="up:RelationBaseType"><choice>

<element name="Organization" type="mpeg7:OrganizationType"/><element name="OrganizationRef" type="mpeg7:ReferenceType"/><element name="PersonGroup" type="mpeg7:PersonGroupType"/><element name="PersonGroupRef" type="mpeg7:ReferenceType"/>

</choice></extension>


<complexType name="FriendType"><complexContent>

<extension base="up:RelationBaseType"><choice>

<element name="Person" type="mpeg7:PersonType"/><element name="PersonRef" type="mpeg7:ReferenceType"/>



<complexType name="PersonalInterestsType"><sequence>

<element name="Activity" type="mpeg7:SemanticBaseType" minOccurs="0" maxOccurs="unbounded"/>

<element name="Interest" type="mpeg7:SemanticBaseType" minOccurs="0" maxOccurs="unbounded"/>

<element name="Favorite" type="mpeg7:SemanticBaseType" minOccurs="0" maxOccurs="unbounded"/>


<complexType name="ExtendedElectronicAddressType"><complexContent>

<extension base="mpeg7:ElectronicAddressType"><sequence>

P2P-Next D5.3.1d

<element name="InstantMessagingScreenName" type="up:InstantMessagingScreenNameType" minOccurs="0" maxOccurs="unbounded"/>


</complexContent></complexType><complexType name="InstantMessagingScreenNameType">

<simpleContent><extension base="string">

<attribute name="service" type="anyURI" use="required"/></extension>

</simpleContent></complexType>

For the media review attributes for individual as well as aggregated reviews, the followingextensions to MPEG-7 are proposed:

<complexType name="MediaReviewBaseType" abstract="true"><complexContent>

<extension base="mpeg7:ContentManagementType"><sequence>

<element name="ContentRef" type="mpeg7:ReferenceType"/><element name="Tags" type="mpeg7:KeywordAnnotationType" minOccurs="0"/><element name="FreeTextReview" type="mpeg7:TextualType" minOccurs="0"

maxOccurs="unbounded"/><element name="MediaRating" type="mpeg7:RatingType" minOccurs="0"

maxOccurs="unbounded"/><element name="IdentityRating" type="mpeg7:RatingType" minOccurs="0"/><element name="QualityRating" minOccurs="0" maxOccurs="unbounded">

<complexType><complexContent>

<extension base="mpeg7:RatingType"><attribute name="type" use="required">

<simpleType><restriction base="NMTOKEN">

<enumeration value="subjective"/><enumeration value="objective"/>

</restriction></simpleType>

</attribute></extension>


</element></sequence><attribute name="reviewTime" type="mpeg7:timePointType" use="required"/>


</complexType>

<complexType name="IndividualMediaReviewType"><complexContent>

<extension base="review:MediaReviewBaseType"><choice>

<element name="Reviewer" type="mpeg7:AgentType"/><element name="ReviewerRef" type="mpeg7:ReferenceType"/>



<complexType name="AggregatedMediaReviewType"><complexContent>

<extension base="review:MediaReviewBaseType">

P2P-Next D5.3.1d

<sequence><element name="ObservationPeriod" type="mpeg7:TimeType"

maxOccurs="unbounded"/><element name="ReviewerCount" type="nonNegativeInteger"/>



3 Kendra SignpostThe Kendra Signpost implementation provides a modular framework with which users can ingestcontent catalogues from existing data stores, map metadata between those catalogues and variousvocabularies, expose semantically rich metadata for discovery and indexing by search engines, andcreate dynamic queries within a web browser using a faceted query interface. Kendra Signpostcodes, which are concise descriptions of ingested content encoded using a mixture of HTML5 andRDFa attributes, provide a structured metadata tagging syntax for a variety of digital media formats,particularly audio, video, and still images. To assist with discovery, a web portal running the KendraSignpost modules can publish an index of pointers to ingested multimedia content and metadataincluding RDFa-enriched HTML markup, thereby making the metadata available for indexing bysearch engines such as Google and Yahoo!, which have begun indexing RDFa content as of late2009.

Figure 2: Kendra Signpost Architecture

P2P-Next D5.3.1d

In addition to a public-facing web server for accessing Kendra Signpost (Apache with mod_php forthe purposes of the prototype [8]), a relational database for storage of content and configuration(MySQL [9]), an RDF triple store for storage of faceted metadata (OpenLink Virtuoso [10]), and asearch and retrieval system for indexing the metadata (Apache Solr [11]), Kendra Signpost iscomprised of four modules, which have been implemented as Features for the Drupal modularframework:

1. Kendra Signpost Upload is a tool for ingestion of metadata from a simple denormalized fileformat. Since many of the content providers targeted by Kendra Signpost store cataloguemetadata in a relational database or spreadsheet format, the most straightforward approachto importing content is the use of an intermediary data format, namely a flat file stored incomma-separated value (CSV) format. The first line of the file contains the names of thecolumn headers, or field labels, and each subsequent line contains the field values for asingle record following the same field sequence as the header row.

2. Kendra Signpost Mapper is a generalised tool for mapping metadata for content ownerswhich includes mapping to the P2P-Next Rich Metadata schema. Kendra Signpost isgeneralized in order to drive adoption: content owners can use the Kendra Signpost mappingtools to link their content to other popular metadata mappings, thereby increasing contentvisibility and discovery.

3. Kendra Signpost Inference Engine is a Python tool which acts as a proxy between the portalhosting the uploaded catalogues, the RDF triple store containing the metadata extracted fromcatalogues, and the client-side web browser which can run queries against the inferredrelations generated by the mapping tool.

4. Kendra Signpost Search is a public-facing query builder which allows end users to quicklybuild queries to find the content that fits their exact criteria, based on the faceted metadatastored within the system. Built in HTML, Javascript, and CSS, the query builder can be usedby most modern web browsers and portable devices to search the indexed metadata in auser-friendly way.

5. NextShare Core Importer is an interface to a headless NextShare Core client connecting tothe NextShare cloud that discovers new files and makes their metadata available in theKendra Signpost system.

6. Kendra Signpost Publisher provides several mechanisms for publishing data in searchengine friendly formats. The result is a catalogue of web pages with embedded RDFa andmicroformat metadata compatible with the Schema.org specification, that leverages theavailable mappings created by the Kendra Signpost Mapper. Search engines can index andthen make use of the RDFa and microformat enriched HTML for providing rich snippets insearch results.

3.1 Vocabulary IngestProducing and consuming metadata is easy: developers select one or more vocabularies andconsume or expose metadata using strict references to those vocabularies using XMLSchema,RDFs, or RDFa. The problem is that there are so many to choose from, and mappings must beclearly defined between them (as is detailed in sections 2.5 and 2.6 of this document). Thisapproach limits the uptake of narrowly-focused vocabularies in general use on the World Wide Web,which has flourished largely due to the inherent freedom to create new domain-specific taggingsystems.

Kendra Signpost provides an alternative for end users which builds on the following process.

P2P-Next D5.3.1d

1. Firstly, discovery metadata relaxes constraints sufficiently that the metadata is regarded assome form of free-form tagging.

2. Secondly, metadata mapping maps metadata ontologies and vocabularies to one another.

The Kendra Signpost / Linked Data Platform metadata system is designed to support multipleontologies with fuzzy relationships between them. The system is initialized with a number ofpredefined well-known ontologies and vocabularies, including Dublin Core, Web OntologyLanguage (OWL), URIplay, and TV-Anytime. All of these can be mapped into the "big table" view,as well as being processable by other semantic tools. The various media-related metadata schemasare then encoded using Drupal-based user-level tools, i.e., as if they were catalogues.

3.2 Content IngestThe semantic data can be regarded as having two kinds: ontologies, and data instances. Thesecorrespond to catalogues and catalogue entries respectively.

There are two node types, referred to as Catalogue and Catalogue Item. A Catalogue represents a(part) of a user's catalogue as imported via the content ingestion process. Here one spreadsheetcorresponds to one node. The catalogue may occupy multiple sheets so each user can have multipleCatalogue nodes. The source spreadsheet is stored in this node, and the mapping informationderived from the file structure is also associated with this node. These default mappings can beautomatically created using the spreadsheet layout (column titles). There is no need for twodifferent namespaces for objects, names and values: everything is ultimately a URI.The Kendra Signpost Upload module enables the user to import Catalogue spreadsheets, and willhandle XML metadata. Catalogues are stored with reference to original file (graph id). Conversionfrom spreadsheet cells is done according to the following table:

RDF entity Catalogue equivalentgraph url for source import nodesubject row identifierpredicate column nameobject cell value

Table 17: RDF entity to Kendra Signpost Catalogue Mapping

3.3 Catalogue MappingsSemantic mappings are being defined between metadata formats. Initially all mappings are definedby mapping to and from P2P-Next metadata. This is not a transformation, but rather a semanticmapping. Queries which reference the other schemas relevant to P2P-Next can be transformed tomatch against the other data using the specified formats.

The Kendra Signpost ontology declares relationships between relationships and relationshipsbetween values. It has no inherent grounding on any media-related vocabulary. Instead, it definesterms like "is similar to", "is a special case of", "is a generalization of", and even "not to beconfused with", and uses these to map relationships between these objects. This will be used in thefuture to allow fuzzy matching in a way that is superior to simply relaxing the semantics ofmetadata and turning it into free tagging.

P2P-Next D5.3.1d

Catalogue heading mapping GUI ("schema mapper")

To use the mapping tool, a user first creates a mapping (just enter title and click submit):

Figure 3: Kendra Signpost Mapping creation

On the following page, mapping items are added to the mapping using the "add mapping" link:

Figure 4: Adding a Kendra Signpost Mapping

Allowed values for the source and destination fields are taken from valid predicate values read fromthe Virtuoso RDF data. Mappings are sent to Virtuoso and are visible to the portal administrator byclicking the "toggle rdf view" link on a mapping node page.

P2P-Next D5.3.1d

Figure 5: Create Kendra Signpost Mapping Pair

Figure 6: Example Kendra Signpost Mappings

P2P-Next D5.3.1d

Multiple mappings are added to each mapping node. And multiple types of mappings can be added.A user can create multiple mapping nodes and use them to group mapping items into logical groups,although this is not a requirement of the system and a user may decide to use just one mapping nodeand add all the mappings they require within it. Mapping items take several forms:

inter-catalogue mappings: mappings from the properties of one catalogue format, to relatedproperties of another metadata format mappings: mappings from properties of a catalogue to the properties withina recognised metadata standard. inter-standard mappings: mappings from properties within one standard to properties ofanother metadata standard format. property typings: mappings that specify the datatype or format of a property within acatalogue or metadata format.

3.4 Facet IndexingAn indexing search engine is used to index the entire collection of triples corresponding to acatalogue node. Apache Solr was used for the M30 prototype. This index will be updatedasynchronously for reasons of scalability, but within no more than 1-2 minutes after updates aremade to the mapping values. Extra index terms may be generated on demand, depending on thecontent of ontology data. These terms will not be user-visible.An alternative approach was also investigated, namely using the RDF triple store (e.g. Virtuoso) todo the semantic lookups and inferencing via OWL, without any external inference engine. Thisapproach requires the same user interface, but wouldn't require Solr or the custom inferencingproxy. This approach would not be able to do fuzzy inferencing, and will be slow. Furthermore,Kendra was able to implement a prototype of the system including the inferencing proxy in lesstime that would be required to do proper inferencing within the triple store.There are two programmatic interfaces to the indexing proxy:

1. Return mapping spec as XML when given a specific spec ID1. Calls to the Solr update proxy are made periodically when content in the Drupal

system is added or updated using the ApacheSolr module for Drupal. 2. The proxy will parse the XML document sent from Drupal, looking for references to

the document URI. 3. For each URI found (i.e. one per uploaded document), the proxy will perform a

SPARQL query to the RDF triple store for all imported triples. 4. The proxy performs inferencing (see section 3.5 for details), using the user-created

mappings to relate terms between multiple schemas. 5. The proxy splices the results into the document in XML format, which is then sent to

Solr for indexing. 2. Return a Javascript Object Notation (JSON) formatted result array from a query (HTTP GET

using parameters in the query string).The format of the query API was designed to be compliant with the Apache Solr faceted search API.Queries are sent in the following URL query syntax:

P2P-Next D5.3.1d

URL queryparameter parameter value Description Comment

wt json return results in JSON format requiredjson.wrf [function name] JSONP callback function required

json.nl map return Solr NamedLists represented as a JSON object simplest mappingof results

facet true enables facet counts in the query response required

facet.missing true return a count of all matching results which have novalue for the field optional

q.alt * : * facet queries will filter from the set of all matches required

fq exampleFacet:"searchphrase"

Filter Query limits the result set to items matching thephrase "search phrase" in the facet "exampleFacet" optional

fq exampleFacet:42 Filter Query limits the result set to items matching thenumber 42 in the facet "exampleFacet" optional

fq exampleFacet.date:"2010-01-01T09:00:00Z"

Filter Query limits the result set to items matching thedate/time 9 AM on January 1, 2010 in the facet"exampleFacet"

optional

fl exampleFacet,exampleFacet2

specify a set of fields to return, limiting the amount ofinformation in the response optional

Table 18: Kendra Search URL Query Parameters

3.5 Inference

Data mining metadata mappingsThere has been considerable work on converting metadata between different metadata standards(see sections 2.5 and 2.6 for examples). The Kendra Signpost effort is taking a different approach tothis, by establishing semantic mappings between metadata standards.

The proposed work will involve extracting the relevant semantic mappings from the availablewritten documentation, and reconstituting these mappings in an RDF-triples format. This will berepresented using "sameAs" or "similarTo" properties, in a representation close to that of OWL.Once this has been done, it will be transformed into a format where it may be fed into the first-stageDrupal test implementation, either as a set of RDF assertions, a CSV table, or as a hardwired datastructure. The necessary textual transformations will be performed programmatically.

In the short term, these semantic mappings will be very simple. However, we hope in the long termto be able to convey much richer semantic mappings than can be expressed by metadata conversion;instead of just mapping between like fields, the system should be able to express the semanticrelationships between the semantic classes and types involved, enabling the expression of shades ofmeaning that may be lost by simple metadata conversion. In addition, these relationships will beable to be used as inputs into inference engines, allowing the creation of semantic mappings whichare only implicitly defined as results of other mappings.As with all mainstream semantic work, Kendra Signpost can import and export data in RDF/N-triples format. Data already represented as RDF can be imported directly into the RDF triple store.XML-only metadata needs first to be converted into RDF, either by using schema-basedconversion , or by using a “natural” representation of generic XML as RDF.Once this is done, we can then look at how we can express the semantic relationships between theresulting RDF graphs. At the moment, we express these relationships in a very simple ad-hoc XML

P2P-Next D5.3.1d

format (see the sample mapping for the "Title" and "Description" fields from the P2P-next to TV-Anytime schemas), which is planned to be a temporary measure before we move to standards-basedrepresentations in the next phase of our work. OWL is ideal for representing simple relationshipsbetween RDF properties and types. However, we are still investigating how we can represent morecomplex relationships involving nested XML constructs that thus have more complex RDFinterpretations. It looks likely that this may be solvable using a combination of simple mappingsand inference. The issues of how to represent mappings involving bag/collection-based content orwhere data orderings are important, also need investigating. However, we believe that some thesesorts of fine distinctions may be unnecessary for the limited scope of the current work.<signpost_mappings><signpost_mapping> <from_scheme name="P2P-next"> <attribute>Title</attribute> </from_scheme> <to_scheme name="TVA"> <attribute>BasicContentDescriptionType</attribute> <type>Title</type> </to_scheme></signpost_mapping><signpost_mapping> <from_scheme name="P2P-next"> <attribute>Description</attribute> </from_scheme> <to_scheme name="TVA"> <attribute>BasicContentDescriptionType</attribute> <type>Synopsis</type> </to_scheme></signpost_mapping></signpost_mappings>

3.6 Query Selection

Smart Filter formatThe design of this "Smart Filter" query builder was based on user interface cues taken from the"Smart Playlist" interface developed for many popular operating systems. The Smart Filter interfaceprovides a simple but powerful tool for building complex queries, using operators dynamicallydetermined from the datatype of the property (facet) being searched via the schema mappings,extended numeric and date/time range support, and allowing for nested Boolean AND and ORoperations.

P2P-Next D5.3.1d

Figure 7: Kendra Signpost Smart Filter Interface

3.7 Kendra Signpost Output

Kendra Signpost codeKendra Signpost code may be embedded in web pages using a combination of HTML and RDFasyntax which is compatible with both the XHTML 1.1 and HTML5 (draft) standards. The followingis an example of encapsulation of a Kendra Signpost code to relate content metadata to anexternally linked music video. Note that HTML5 is required for use of the <video/> tag; otherwisean alternate video distribution method should be used.<div xmlns:dc="http://purl.org/dc/" xmlns:dcterms="http://purl.org/dc/terms/" xmlns:play="http://ref.atlasapi.org/" xmlns:po="http://purl.org/ontology/po/" xmlns:mo="http://purl.org/ontology/mo/" xmlns:video="http://purl.org/media/video#" xmlns:kendra="http://kendra.org.uk/terms/#" rel="po:Programme" about="http://example.com/video/music/225/h264-svc/p2pnext" typeof="video:Recording"> <div class="title"> <a rel="mo:homepage" href="http://example.com/artist/" property="kendra:artist">Example Artist</a> <span rel="dc:title">2 + 2 = 5</span> </div> <p rel="dc:description" class="description">

... an example description of the contained content</p>

<div class="hidden"> <span rel="kendra:isrc">GB-040-03-0112-0</span> <div rel="dcterms:rightsHolder" resource="http://example.com/" /> </div> <div rel="kendra:thumbnail">

P2P-Next D5.3.1d

<img src="http://example.com/rad/p2p-next/test-content.jpeg" /> </div> <div rel="kendra:genre">Rock music</div> <div rel="po:Version" about="http://example.com/video/music/225"> <div class="length">Length (seconds): <span rel="po:duration">600</span></div> <div rel="play:manifestedAs"> <div rel="play:availableAt"> <div rel="play:Location" about="http://example.com/video/music/225/h264-svc/p2pnext"> <video rel="play:uri" resource="http://example.com/video/music/225/test-content-a-svc.mpeg" /> </div> </div> </div> </div></div>

3.8 NextShare Core Integration

NextShare Core ImporterThe import process begins with an installable NextShare core for Linux creating ATOM feed codethat is output to files that are read by the Kendra Signpost system.A headless implementation of the P2P-Next NextShareCore client, running on a Linux server whichis permanently connected to the cloud, issues requests for new content to its peers via theBuddyCast [12] protocol. Those peers respond (asynchronously, ideally) with .tstream (torrent) filescontaining content metadata. Unique and new torrent metadata is stored in an on-disk cache. Newcontent metadata discovered via this process are buffered and then relayed to the Kendra Signpostindexing layer, periodically as a response to a request from the Feeds Aggregator. Output from theheadless NextShare Core instance can be found at:http://nextsharecore.kendra.org/nextshare-core-raw.txt

P2P-Next D5.3.1d

The importer system is configurable in 3 parts. The Fetcher is configured to import content from aHTTP source. The parser is configured to use a custom parser designed specifically for the metadata

Figure 8: Raw output from the headless NextShare Core instance

Figure 9: Metadata mapping in the NextShare Core Importer

P2P-Next D5.3.1d

format that is returned from items in the NextShare cloud. The third part of the configuration is theProcessor, which in this case maps the parsed data on to nodes in the Kendra Signpost system:

These results can then be seen importing live into the Kendra Signpost system at:

http://live.signpost.kendra.org.uk/nextshare-live

Figure 10: NextShare Core Importer results

P2P-Next D5.3.1d

Kendra Signpost Generic Importer

A generic importer has been implemented to import content from other sources. A set of standardmappings are defined in the Feed Importer section, content with these standard fields (such asArchive.org) can then be imported from XML, CSV or JSON with these fields automatically set upfor import to the Kendra Signpost system.

These results appear along side other results and can be output as RDF, Rich-snippets. This exampleshows an extract form the imported content taken from a feed of the most popular items onArchive.org.

Figure 11: Processing Archive.org content with the Generic Importer

P2P-Next D5.3.1d

Kendra Signpost Publisher

Content metadata containing links for all discovered torrents will then be promptly indexed andavailable as individual public HTML pages with embedded "rich snippets". Google, Microsoft, andYahoo! support a specific format of microdata which they call Rich Snippets. Based on aspecification which they collectively proposed and accepted without public discussion, published atSchema.org, rich snippets allow a website editor to mark up their data using a hierarchical set ofterms which characterise the content and make it more understandable for search engines to indexfor the purpose of improving their capability to make inferences with other indexed content.

See: http://www.google.com/webmasters/tools/richsnippets

Figure 12: Metadata mapping in the Generic Importer

P2P-Next D5.3.1d

The data is published in the online catalogue based on the mappings that are available. Thecatalogue is indexed by search engines, so additional metadata formats are embedded using themicroformats that search engines read, in particular the schema.org formats. In order for thecatalogue to do this there must be mappings available from the source metadata formats. Mappingsbundled with the Kendra Signpost system deal with the mapping form MPEG7 to schema.org,ensuring that most content can be automatically mapped on to the required formats, and a contentprovider can easily enable rich snippets for their content by mapping their metadata format toMPEG7 or schema.org using the mapping tools.

Indexed content will also be available to the public via the Smart Filter interface.

3.9 Kendra Signpost Modules

Components of the system

Drupal FrameworkThe system is built on top of the Drupal framework. The core Drupal content management featuresare extended with a selection of contributed modules from the Drupal ecosystem of GNU open-source licensed modules, and some modules developed specifically for the project.

We use a 'Features' based methodology that packages custom code and exportable Drupalconfiguration to a module package for distribution. All required features modules for building thetrial application are packaged as an 'Install profile' that can be downloaded and installed on anyserver. The required functionality is automatically configured by the install profile and featuresmodules.

Figure 13: Google's Rich Snippets Testing Tool

P2P-Next D5.3.1d

Virtuoso Triple Store

We use a dedicated RDF store for storage of triples. This is provided by using Virtuoso, andaccessing the RDF store via the SPARQL endpoint it provides.

Solr Search IndexImported catalogues and catalogue items are treated as 'documents' for the purpose of indexing bythe search index. Properties are added to the documents to form 'facets' for performing advancedsearch and browsing of the catalogues.

Inference EngineThe inference engine works as a proxy between the Drupal front-end and the Solr search service. Itintercepts "Update" requests to insert it's own inferred data into documents before they are indexedby the search server. It also intercepts search requests to perform any required manipulation of thequery and format inferred data before it is returned to the search front end.

NextShare Core Importer

This module enables metadata within the raw .tstream (torrent) files, output by the headlessNextShare Core instance, to be imported to the Kendra Signpost system.

Kendra Signpost Generic ImporterEnables us to import many different types of content metadata feeds.

Kendra Signpost PublisherEnables us to publish metadata that the major search engines will recognise and intepret in asemantic way.

Features Modules

The functionality is split into several features:Search - provides the search interface and integration of the front end with the Solr searchservice. Upload - provides ingestion of catalogue data, and creation of Drupal nodes. Mappings - provides the mapping GUI interface, and the node types for management ofmappings and metadata formats. RDF - provides an abstraction layer around the interface from various Drupal modules to theSPARQL end point of the Triple store.

3.10 ConclusionThe Kendra Signpost prototype has successfully ingested content catalogue metadata fromrecording labels including Real World and Third Ear, mapping fields from P2P-Next and DublinCore. Further improvements to the prototype should include an Atom Feed parser and generatorwith intended compatibility with the P2P-Next Web Portal. Now the Kendra Signpost system hassuccessfully integrated with the NextShare cloud by being able to ingest NextShare content

P2P-Next D5.3.1d

metadata into the Kendra Signpost live. Additional areas of research and improvement includefuzzy reasoning within imported RDF vocabularies and additional RDFa publishing support forupcoming versions of Drupal.

3.11 Future WorkAs P2P-Next draws to a close the Kendra Signpost system has been adopted by and integrated intotwo European projects: Saracen (Socially Aware, collaboRative, scAlable Coding mEdiadistribution) EC FP7 STREP commenced early 2010 and due to finish at the end of 2012; andMediaMap+ Celtic-Plus due to commence in early 2012. Both these projects will extend the KendraSignpost concept and tool set. Further work includes: wrapping the Smart Filter system andmetaphore as a coherent "standards" offering. Extending the mapping interface to enable any user(content owner or content consumer) to be able to define their own "name space" (terminology theyuse and what it means to them).

P2P-Next D5.3.1d

4 Content CollectionsThe P2P-Next Rich Metadata, as defined in Section 2, describes the attributes for individual contentitems. The Atom Syndication Format (Atom) [13] is an IETF-approved format that provides a wayof describing lists of related items. Although widely used on the Internet for weblogs and newsarticles, Atom is also designed to describe lists of data and metadata items. Along with RSS, Atomhas become established on the Web as a way of both syndicating content between providers anddistributors, and delivering content directly to consumers.

Atom is widely supported, with libraries available for most programming languages to easilyproduce and consume Atom feeds. Atom can be extended to add elements from external markupvocabularies through the use of XML namespaces, which means that any additional metadataelements specific to the NextShare system can be easily introduced.

In P2P-Next, Atom is used as a way for content providers to describe the content they haveavailable. Three types of Atom feed are described in this section: the “master discovery feed”(section 4.1), the “discovery feed” (section 4.2) and the “content feed” (section 4.3).The BBC has implemented a Web service that provides Atom feeds containing schedule informationfor the BBC live TV and radio streams distributed via P2P, and ULANC implemented the masterdiscovery feed that links to the BBC, NORUT, and ULANC discovery feeds.

4.1 Master Discovery FeedThe master discovery feed acts as the main point of entry for content discovery for NextShareclients (NextShareTV and NextSharePC), and serves to aggregate together a set of discovery feeds,one from each content provider.The <feed> element contains the following child elements:


<title> The name of the master discovery feed, e.g.,"NextShare".

<link rel="self"> The URI of the master discovery feed.

<author> The author of the master discovery feed. This is notintended for display to users.

<id> A unique identifier (URN) for the master discoveryfeed. See reference [1], Annex A.

<updated> The time and date the feed was last updated.

<p2pnext:image> The "src" attribute of this element contains the URL ofa logo image for the master discovery feed (see section4.3 for more information).

Table 19: The discovery feed elementThe <feed> element contains one <entry> element for each content provider. Each <entry>element in the feed contains the following child elements:

P2P-Next D5.3.1d


<title> The name of the content provider, e.g., "BBC".

<id> A unique identifier (URN) for the Discovery Feed. Seereference [1], Annex A.


<p2pnext:image> The "src" attribute of this element contains the URL ofa logo image for the Discovery Feed (see section 4.3for more information).

<link> The URI of the Discovery Feed (see section 4.2).

Table 20: The discovery entry elementAn example master discovery feed is shown below.<feed xmlns="http://www.w3.org/2005/Atom" xmlns:p2pnextfeed="urn:p2pnext:contentfeed:2009"> <title>ULANC IPTV</title> <link rel="self" href="http://stb.iptv.lancs.ac.uk/master-feed" /> <author> <name>ULANC</name> </author> <id>urn:p2p-next:aggregator:ulanc</id> <updated>2011-09-03T08:51:00Z</updated> <p2pnextfeed:image src="http://stb.iptv.lancs.ac.uk/images/p2pnext.png" /> <entry> <title>BBC</title> <link type="application/atom+xml" href="http://www.bbc.co.uk/content/feed/bbc" /> <id>urn:p2p-next:provider:bbc</id> <updated>2011-09-03T08:51:00Z</updated> <p2pnextfeed:image src="http://www.bbc.co.uk/images/bbc.png" /> </entry>

<entry> <title>Far North Living Lab</title> <link type="application/atom+xml" href="http://farnorthlivinglab.no/feed" /> <id>urn:p2p-next:provider:farnorthlivinglab</id> <updated>2011-09-03T08:51:00Z</updated> <p2pnextfeed:image src="http://farnorthlivinglab.no/images/logo.png" /> </entry></feed>

4.2 Discovery FeedThe discovery feed contains a list of available live services or on-demand content collections, froma single content provider, and is intended to serve as the feed from which all of the provider'savailable content can be discovered.The <feed> element contains the following child elements:

P2P-Next D5.3.1d


<title> The name of the content provider, e.g., "BBC".

<link rel="self"> The URI of the discovery feed.

<author> The author of the discovery feed. This is not intendedfor display to users.

<id> A unique identifier (URN) for the discovery feed. Seereference [1], Annex A.


<p2pnext:image> The "src" attribute of this element contains the URL ofa logo image for the discovery feed (see section 4.4for more information).

Table 21: The discovery feed element

The <feed> element contains one <entry> element for each of the content provider's live servicesor content collections. Each <entry> element in the feed contains the following child elements:


<title> The name of the service or content item collection,e.g., "BBC One".

<category scheme="urn:service-type">

The "term" attribute of this element indicates whetherthe content feed contains either TV (term="tv") orradio (term="radio") items.

<id> A unique identifier (URN) for the content feed. Seereference [1], Annex A.


<p2pnext:image> The "src" attribute of this element contains the URL ofa logo image for the content feed (see section 4.3 formore information).

<link> The URI of the content feed (see section 4.3).

Table 22: The discovery entry element

An example discovery feed is shown below.<feed xmlns="http://www.w3.org/2005/Atom" xmlns:p2pnextfeed="urn:p2pnext:contentfeed:2009"> <title>BBC</title> <link rel="self" href="http://www.bbc.co.uk/content/feed/bbc" /> <author> <name>BBC</name> </author> <id>urn:p2p-next:provider:bbc</id> <updated>2009-11-19T00:10:00Z</updated> <p2pnextfeed:image src="http://www.bbc.co.uk/images/bbc.png" /> <entry> <title>BBC One</title> <link type="application/atom+xml" href="http://www.bbc.co.uk/content/feed/bbc/bbcone" /> <category scheme="urn:service-type" term="tv" /> <id>urn:p2p-next:service:bbc-bbcone</id> <updated>2009-11-19T00:10:00Z</updated> <p2pnextfeed:image src="http://www.bbc.co.uk/images/bbcone.png" /> </entry>

P2P-Next D5.3.1d

<entry> <title>BBC Radio 4</title> <link type="application/atom+xml" href="http://www.bbc.co.uk/content/feed/bbc/radio4" /> <category scheme="urn:service-type" term="radio" /> <id>urn:p2p-next:service:bbc-radio4</id> <updated>2009-11-19T00:10:00Z</updated> <p2pnextfeed:image src="http://www.bbc.co.uk/images/radio4.png" /> </entry></feed>

4.3 Content FeedThe content feed contains a list of available content items within a collection. This could beprogrammes in a series for an on-demand collection, or schedule entries for a live TV or radiobroadcast.

The <feed> element contains the following child elements:


<title> The name of the service or content item collection,e.g., "BBC One".

<link rel="self"> The URI of the content feed.

<author> The author of the content feed. This is not intendedfor display to users.

<id> A unique identifier (URN) for the content feed. Seereference [1], Annex A.


<p2pnext:image> The "src" attribute of this element contains the URL ofa logo image for the content feed (see section 4.4 formore information).

Table 23: The content feed element

The <feed> element contains one <entry> element for each individual content item. Each<entry> element in the feed contains the following child elements:

P2P-Next D5.3.1d


<title> The programme title (the Title attribute in section2.1).

<summary> The programme description (the Description attributein section 2.1).

<id> A unique identifier (URN) for the programme. Seereference [1], Annex A.


<p2pnext:image> The src attribute of this element contains the URL of alogo image for the content item (see section 4.4 formore information).

<p2pnext:broadcastType> Indicates whether this is a live or ondemand item (seesection 4.4).

<p2pnext:mediaUri> The URI of the media stream for this content item (seesection 4.4).

<p2pnext:timePoint> For a live stream, the start time of this content item(see section 4.4).

<p2pnext:mediaDuration> The duration of this content item (see section 4.4).

<link> A link to the TV-Anytime, MPEG-7, or URIplay metadatafor the programme. This element would not be present ifthe <entry> contains a <content> element.

<content> Contains the TV-Anytime, MPEG-7, or URIplay metadatafor the programme. This element would not be present ifthe <entry> contains a <link> element.

Table 24: The content entry element

An example content feed, with links to separate content item metadata is shown below.<feed xmlns="http://www.w3.org/2005/Atom" xmlns:p2pnextfeed="urn:p2pnext:contentfeed:2009"> <title>BBC One London</title> <link rel="self" href="http://www.bbc.co.uk/content/feed/bbc/bbcone" /> <author> <name>BBC</name> </author> <id>urn:p2p-next:bbc-bbcone</id> <updated>2010-10-12T23:10:00Z</updated> <p2pnextfeed:image src="http://www.bbc.co.uk/images/bbcone.png" /> <entry> <title>Weatherview</title> <link type="application/xml" href="http://www.bbc.co.uk/content/info/bbc/bbcone/b00p1f8v" /> <id>urn:p2p-next:item:bbc-bbcone-b00p1f8v</id> <updated>2010-10-12T23:10:00Z</updated> <summary>Detailed weather forecast.</summary> <p2pnextfeed:image src="http://www.bbc.co.uk/images/b007yy70_150_84.jpg" /> <p2pnext:broadcastType>live</p2pnext:broadcastType> <p2pnext:mediaUri> http://p2pnext-swarm-one.lancs.ac.uk/live/BBC1.mpegts.tstream </p2pnext:mediaUri> <p2pnext:timePoint>2010-10-08T12:00:00+00:00</p2pnext:timePoint> <p2pnext:mediaDuration>PT0H10M0S</p2pnext:mediaDuration> </entry> <entry> <title>James May's Toy Stories Airfix</title> <link type="application/xml" href="http://www.bbc.co.uk/content/info/bbc/bbcone/b00nnm3d" />

P2P-Next D5.3.1d

<id>urn:p2p-next:item:bbc-bbcone-b00nnm3d</id> <updated>2010-10-12T23:10:00Z</updated> <summary>James May tries to make a full-size Spitfire out of Airfix. Are the pieces strong enough?</summary> <p2pnextfeed:image src="http://www.bbc.co.uk/images/b00nqmlb_150_84.jpg" /> <p2pnext:broadcastType>live</p2pnext:broadcastType> <p2pnext:mediaUri> http://p2pnext-swarm-one.lancs.ac.uk/live/BBC1.mpegts.tstream </p2pnext:mediaUri> <p2pnext:timePoint>2010-10-08T12:10:00+00:00</p2pnext:timePoint> <p2pnext:mediaDuration>PT0H50M0S</p2pnext:mediaDuration> </entry> <entry> <title>Country Tracks Central England</title> <link type="application/xml" href="http://www.bbc.co.uk/content/info/bbc/bbcone/b00p6d9v" /> <id>urn:bbc-bbcone-b00p6d9v</id> <updated>2009-11-19T00:10:00Z</updated> <summary>Ellie Harrison begins a journey through Central England, riding with a Veteran Cycle Club.</summary> <p2pnextfeed:image src="http://www.bbc.co.uk/images/b00k4l44_150_84.jpg" /> <p2pnext:broadcastType>live</p2pnext:broadcastType> <p2pnext:mediaUri> http://p2pnext-swarm-one.lancs.ac.uk/live/BBC1.mpegts.tstream </p2pnext:mediaUri> <p2pnext:timePoint>2010-10-08T13:00:00+00:00</p2pnext:timePoint> <p2pnext:mediaDuration>PT0H30M0S</p2pnext:mediaDuration> </entry> </feed>

An example content feed, with contained MPEG-7 metadata is shown below.

<feed xmlns="http://www.w3.org/2005/Atom" xmlns:p2pnextfeed="urn:p2pnext:contentfeed:2009"> xmlns:p2pnext="urn:p2pnext:metadata:2008" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:mpeg7="urn:mpeg:mpeg7:schema:2001"> <title>BBC One London</title> <link rel="self" href="http://www.bbc.co.uk/content/feed/bbc/bbcone" /> <author> <name>BBC</name> </author> <id>urn:p2p-next:bbc-bbcone</id> <updated>2009-11-19T00:10:00Z</updated> <p2pnextfeed:image src="http://www.bbc.co.uk/images/bbcone.png" /> <entry> <title>Weatherview</title> <link type="application/xml" href="http://www.bbc.co.uk/content/info/bbc/bbcone/b00p1f8v" /> <id>urn:p2p-next:item:bbc-bbcone-b00p1f8v</id> <updated>2009-11-19T00:10:00Z</updated> <summary>Detailed weather forecast.</summary> <p2pnextfeed:image src="http://www.bbc.co.uk/images/b007yy70_150_84.jpg" /> <p2pnext:broadcastType>live</p2pnext:broadcastType> <p2pnext:mediaUri> http://p2pnext-swarm-one.lancs.ac.uk/live/BBC1.mpegts.tstream </p2pnext:mediaUri> <p2pnext:timePoint>2010-10-08T12:00:00+00:00</p2pnext:timePoint> <p2pnext:mediaDuration>PT0H10M0S</p2pnext:mediaDuration> <content>  </content> </entry>

P2P-Next D5.3.1d

</feed>

4.4 Content Feed NamespaceThe P2P-Next content feed namespace is intended to extend the Atom Syndication Format to adddata items that are needed in the context of the NextShare system.

The content feed namespace is:xmlns:p2pnextfeed="urn:p2pnext:contentfeed:2009"

This namespace defines the following elements:<complexType name="ContentFeedImageType"> <attribute name="src" type="anyURI"></attribute></complexType>

<simpleType name="DurationType"> <restriction base="string"> <pattern value="\-?P(\d+D)?(T(\d+H)?(\d+M)?(\d+S)? (\d+N)?)?(\d+F)?((\-|\+)\d{2}:\d{2}Z)?"/> </restriction></simpleType> <simpleType name="BroadcastTypeType"> <restriction base="NMTOKEN"> <enumeration value="live"/> <enumeration value="ondemand"/> </restriction> </simpleType> <simpleType name="TimePointType"> <restriction base="string"> <pattern value="(\-?\d+(\-\d{2}(\-\d{2})?)?)? (T\d{2}(:\d{2}(:\d{2}(:\d+)?)?)?)?(F\d+)?((\-|\+)\d{2}:\d{2})?"/> </restriction></simpleType>

<element name="image" type="p2pnext:ContentFeedImageType"></element><element name="mediaDuration" type="p2pnext:DurationType"></element><element name="broadcastType" type="p2pnext:BroadcastTypeType"></element><element name="mediaUri" type="anyURI"></element><element name="timePoint" type="p2pnext:TimePointType"></element>

Some P2P-Next content is initially streamed live, then subsequently made available on-demand, sothe p2pnext:broadcastType and p2pnext:mediaUri elements are designed to handlethis transition, in order to enable content navigation, search and discovery in live and on-demandphases.

The atom:icon and atom:logo elements were not used for the feed images, because of thefollowing constraints on these elements in the Atom Syndication Format specification, consistentwith the interpretation advised in [14]:atom:icon - “The image SHOULD have an aspect ratio of one (horizontal) to one (vertical) and

SHOULD be suitable for presentation at a small size”

atom:image - “The image SHOULD have an aspect ratio of 2 (horizontal) to 1 (vertical)”

P2P-Next D5.3.1d

5 Content DiscoveryOne important application of the metadata is to utilize the information provided to search forcontent items. This section describes the exploratory research conducted on how this feature couldbe implemented. Key research questions are how to link content discovery with other componentsand how to best pass information between them.

Content discovery implies that the search interface needs to interact with the NextShare core. Wecreated experimental code to explore how this could operate. The result of our experiment is shownin Figure 14.

Content providers can offer a search box on their NextShare-enabled web pages which allows theuser to query the sources. The source users can query a list of Atom feeds provided by the contentprovider as described in Section 4. This feed collection is listed as the MetaFeed. Thus, contentproviders just add a simple HTML form to their Web page, in addition to the code to startNextShareCore:

<form method="get" action="http://127.0.0.1:6879/search"> <input type="text" name="q" size="31" maxlength="255" value=""/> <input type="submit" value="NSSA Search"/> <input type="radio" name="collection" value="metafeed"/> MetaFeed <input type="radio" name="collection" value="buddycast" checked/>BuddyCast<br/> <input type ="checkbox" name="advq" value="False"/> Advanced Query <br /> <input type="hidden" name="metafeed" value="http://bbc.co.uk/content/feed/ns"></form>

Figure 14: HTML Search Form

P2P-Next D5.3.1d

The form will be sent as a HTTP POST request to the NextShare core sharing Agent SearchServerlistening on local port 6878 (see below), in application/x-www-form-urlencoded format. In thiscase the user can select the collection to search in either the provider's list of Atom feeds (defined inthe metafeed value) or BuddyCast. The return to the HTTP POST request is an Atom feedcontaining an entry for each hit. The entry links to a MPEG7 Rich Metadata description of thecontent as defined in Section 2.6 (the HTTP server for these links is the SearchServer). The Atomfeed of the search results are shown in Figure 15.

An optional second source is the BuddyCast peer-to-peer overlay network. As described in [12], theNextShare core contains an epidemic protocol for content discovery and remote querying. When auser types a query in the search box, this query is sent to its 10 connected taste buddies and 10random other peers. It has been shown that this collaborative filtering via semantic peer-clusteringresults in good hit rates. The latter allows the content provider the option of centralized controlbefore deploying the fully decentralized BuddyCast solution. In the case of BuddyCast the queryresults from the remote peers may not come in until after some time. To still achieve good responsetime to queries we therefore return the list of hits in multiple parts. The initial Atom feed returnedcontains only hits from the peer's local database. In addition, it contains a link-tag that will yield anAtom feed from the SearchServer containing the local hits and any remote hits that have arrived in

Figure 15: Search Results of a MetaFeed search

P2P-Next D5.3.1d

the meantime when retrieved. This link may have to be refreshed multiple times to get a completelist of hits. The Atom feed return by the HTTP POST request is meant to be parsed by the Web pagevia JavaScript and rendered to the user in a friendly layout. Figure 16 shows how search result fromthe peer-to-peer overlay network are formatted using the Rich Metadata specification.

To provide a more comfortable way of searching, it is also possible to utilize the P2P-Next RichMetadata core elements for the BuddyCast peer-to-peer search. The HTML form of the search pageprovides a check box named „Advanced Query Format“ which enables/disables the Rich Metadata-based search. If enabled, the search supports all metadata core elements that are defined in section2.6. The advanced query string is a boolean expression that consists of attribute/value pairs. Theattribute describes which core element is addressed by the search. The value restricts this attribute.The advanced query supports all common comparison operators (e.g., less than, equals) to comparea core attribute against a value and boolean operators (i.e., OR, AND, NOT) to combine two ormore expressions. Additionally, parenthesis can be used to express the order of operations. Theadvanced query string allows a user to express a wide range of queries. For instance, to search forall releases named „Memento“ that come with an aspect ratio of „16:9“, the query string looks asfollows: title=Memento && ratio=16:9To further restrict the results to releases that offer HD quality the query could be extended:title=Memento && ratio=16:9 && (height=720 || height = 1080)The search prototype offers a very simple search interface. The query string has to be manuallyinserted and there are no input aids. However, this allows an experienced user to perform complex

Figure 16: MPEG-7 Description of a BuddyCast Search Result

P2P-Next D5.3.1d

queries.To provide a more convenient search interface for users, the generation of the actual query stringcan be hidden from the users by providing a search page and generating the query string usingJavaScript or similar technologies. An example for such a search page is shown in Figure 17.

The search page provides separate fields to specify different search criteria. Furthermore, forknowledgeable users, an OpenSearch [15] plug-in is provided, which allows the user to submitquery strings to NextShare at any time using the search box of a browser supporting OpenSearch(e.g., Firefox).

6 Software PackagesThe metadata APIs, the implementation for content collections, and the content discovery usingRich metadata, have been integrated into NextShare and are provided as part of the NextSharesoftware package [12]. The Kendra Signpost implementation imports metadata from NextShare andis provided as part of this deliverable. It's usage is described below.

6.1 Kendra Signpost ImplementationThe Kendra Signpost implementation is delivered together with this document. Additionally, the

Figure 17: Customized Rich Metadata search

P2P-Next D5.3.1d

source code is available at GitHub (https://github.com/kendrainitiative/kendra_signpost_trial/). Thesoftware package provides the Kendra Signpost implementation as illustrated in Figure 2 anddescribed in detail in Section 3. For detailed information on the installation and requirements of thesoftware package please refer to the INSTALL-file.

P2P-Next D5.3.1d

7 References

[1] D5.2.1, Content ingest and adaptation tools, P2P-Next project deliverable, M. Eberhard.December 2011.

[2] TV-Anytime; Part 3: Metadata; Sub-Part 1: Phase 1 – Metadata Schemes, ETSI TS 102 822-3-1 V1.4.1 (2007-11).

[3] ISO/IEC 15938-5 (2003): "Information technology - Multimedia content descriptioninterface - Part 5: Multimedia description schemes".

[4] URIPlay: http://uriplay.org/. [5] ISO/IEC 21000-17 (2006): "Information technology – Multimedia Framework (MPEG-21) -

Part 17: Fragment Identification of MPEG Resources".[6] ISO/IEC 21000-7 (2007): "Information Technology - Multimedia Framework (MPEG-21) -

Part 7: Digital Item Adaptation". [7] D2.2.1, Requirement, Business Model, Regulation, Legal Aspects Report, P2P-Next project

deliverable, S. Preiss. December 2011.[8] Apache HTTP Server Project, http://httpd.apache.org/.[9] MySQL Open Source Database, http://www.mysql.com/.[10] OpenLink Virtuoso Universal Server, http://virtuoso.openlinksw.com/.[11] ApacheSolr, http://drupal.org/project/apachesolr.[12] D4.0.6, NextShare Platform M48, P2P-Next project deliverable, A. Bakker.

December 2011.[13]RFC 4287, The Atom Syndication Format, December 2005.[14]RFC 2119, Key words for use in RFCs to Indicate Requirement Levels, March 1997.[15] OpenSearch, http://www.opensearch.org/.