Loading ...
Sorry, an error occurred while loading the content.
 

Proposition for a 1.6 spec of mediaRSS

Expand Messages
  • michel_plu
    During our work in the Pharos project ( http://www.pharos-audiovisual-search.eu/) , a european collaborative research project, we have been working and have
    Message 1 of 1 , Mar 15, 2010
      During our work in the Pharos project ( http://www.pharos-audiovisual-search.eu/) , a european collaborative research project, we have been working and have experimented an extension of mediaRSS for supporting innovative content access functionalities

      Even if, we have been really interested by the new 1.5 specification of the media RSS schema , we think that they are still oportunities for some usefull improvements.

      I don't know what would be the most efficient tool to support this discussion but this forum might be a good start.
      I apologize for the length of the post (- a wiki might have been a better solution )- but let's start like this

      I would really apreciate opinions and feedback about working on such an improved version of the media RSS schema and about the precise proposition below

      best regards

      michel plu ( R&D Engineer at Orange Labs )



      Here is the list of Suggestions for improvements extracted from our work in the pharos project :

      1 <media:scenes>

      We think that the name "scene" is not a right name. We think that a right name could be "segment". In fact there migh be many different types of segments which can be described and a scene is only just one very specific .
      a usefull attribute of this renamed <media:segment> element could thus be a segmentType with possible values like( shot, speaker turn, audio, music, speech, ...)

      In order to improve readability, XPAth selection , and homogenity of the spec, we also think that this <media:segment> element should have a "start" and "end" attribute like the <media:text> element in order to precise the temporal position of the segment in the described item


      2 lang attributes in all textual XML elements
      It was found a critical lack not to be able to precise the language of textual descriptions, being titles, keywords or descriptions. This attribute would enable the production of description in multiple languages. It would enable the inclusion of mutliple version of these textual descriptions - This lang attribute would enable an adpated presentation of the described items according to the language of the user and could also reduce "understanding" confusions

      3 "source" attribute for keywords
      Since keywords are important pieces of information to index and retrieve contents , it is important to be able to include and distinguish keywords provided by multiple sources - Thoses sources can be for example multiple personnes including end users or personnes having some credit in the production of the content - Those keywords could also be automatically generated by any piece of software - All these cases could be distinguished according to the ascribed value of a "source" attribute.

      4 "confidence" and "significance" attributes for keywords
      Since those keywords can be produced automatically, including state of the art media technologies for automated content processing , it could become important to provide some confidence measure about these keywords .
      In complement, a "significance" attribute could also precise how much a keyword is representing or being adressed in the described content
      These values would be really usefull in order to rank or filter content descriptions agregated from multiple sources.

      Third party added value services could also improve and enrich original feeds by providing their own values of those attributes for existing or new keywords.
      UI of RSS readers could then be free to use their own ranking or filtering algorithms based of keywords from their selected sources.

      5 "category" attribute for keywords
      Facet based search is also becoming a major functionality in many content access services . It allows users to cluster or filter list of contents according to their interest. Having more information on the nature of the keywords describing an item would support this usefull facet based search functionality. We propose to add a category attribute to <media:keywords> element. Possible values could be "person:name" "organisation:name" "location:name" "topic" "music:genre" etc ... A scheme or method for defining those commonly agreed names can be discussed , but adding a new possible value should be really flexible and should not violate any schema conformance testing.

      6 "media" attribute for keywords
      since audio visual content are multi media , it could also be usefull to precise which part ( media) of an audio visual item is described by a keyword . For example some keywords can be specific to the audio track ( for example music description ) whereas some keywords can be specific to images. Once again, this extra information would enable the user to navigate and filter list of items agregated from multiple feeds.


      4.7 content identification
      A key issue for content aggregator services is to be able to detect and manage duplicates of contents coming from the same or different sources.
      the mediaRSS schema should include new XML elements to precise the identification of contents. One way is to be able for example to provide a link to fingerprints ( or signature) wich can be compared for contents related to the described item .
      Of course,to be compared, all fingerprints must come from the same source. Once again those trusted source of fingerprints could be provided by new third party services
      (see for example the audible magic : http://www.audiblemagic.com/products-services/registration/ )
      Access to such fingerprints, can be achieved by including URLs of a fingerprint in a <media:fingerprint> XML element.

      Inlusion of stadardized identification number (like ISBN for books) in the <rss:guid> can be also usefull , but a "registrar" atribute for this <rss:guid> XML element would be meaningfull to compare ids and be able to publish multiple ids for a content

      8 Keyframes, thumbnail, and snapshot are different
      We all know the power of images for seducing and atracting users . Therefore more and more videos items are presented with more and more keyframes with links included in the item description of the media feeds.
      According to the user interface of the service, only the best keyframe must be selected in order to be presented to the user. This selection will not be the best one if made randomly or automatically. Moreover, also legal impacts can be raised. Thus, this choice must be an editorial one. This choice must be explicit and it can be expressed by distinguishing all keyframes of the selected thumbnail with different XML elements, respectively named keyframe and thumbnail. Another distinguished XML element can also be added for snapshots.
      A snapshot is not a keyframe, since it is not a picture originally coming from the original content item but rather it is an extract of a keyframe ( for example a zoomed area ) for emphasing some details present in the described video item .
      9 <media:community>
      We didn't understand why the current sub-elements <media:tags> of the <media:community> element couldn' be expressed as keywords element.
      In fact it seems to us that the pieces of information contained in that element are keywords provided by a specific source : "users".
      Removing unecessary element would simplify the use and exploitation of the feeds in mediaRSS .
    Your message has been successfully submitted and would be delivered to recipients shortly.