Metadata Standard

Brief Notes:

Transmission metadata standard grew out of meeting in Rome - need for common standard - different people had different names for fields eg. some called it Genre, someone else Category, etc. when they were essentially the same thing - made search and aggregation harder.. To facilitate common search, aggregation, have RSS-type feeds ... So that you could do a common search that would search across all sites that followed the standard . To share content in a more sophisticated way, to find content across sites - so we can have a model where sites are independent still communicating with eachother. Status is Plumi is implementing the standard, pad.ma plans to - hope is other systems will too. The Transmission metadata document is a bit of a technical document - EngageMedia has been periperally involved in drafting it - Jan and Jamie have been involved with drafting it + Mick and Zoie .. It's at the 0.9 stage - interested in getting feedback, see what people thought and whether or not it is worth adopting, and what might be needed to be changed.

Q: Whats the distinction between Transmission standard and MediaRSS? A: Transmission is a valid Atom feed, MediaRSS is a RSS 2.0 feed - RSS 2.0 is a copyrighted standard, so technically you are breaking the copyright everytime you make an RSS 2.0 feed that is a derivative of the RSS 2.0 standard.

Atom is a re-working of the IETF, to come up with an XML format that is a W3C standard and that is open, that has a base set of things, but is also extensible to be able to define your own namespaces. So Transmission uses the Atom base and then extends it to suit video ..

Example of Plone .

Atom always links back to itself, unlike MediaRSS (?) .

Difference between iTunes standard, MediaRSS and Transmission Metadata standard - specific to Genres - something to research ...

the URL's in the transmission metadata standard should use a Subdomain - like xml.ns.transmission.cc/genre, instead of transmission.cc/genre .

The Genre list at Transmission defines a Namespace that is derived from the Genre list specified by IMDB .

What is the rationale behind creating a separate standard? Atom is one of the key differences. It is a lot more extensible. Questions still remain on iTunes standard, MediaRSS and why this (the Transmission standard) might be better.

Explanation on the page (please add link.)

Q: On pad.ma, we have a format for adding data that is time-code specific. Does the Transmission standard plan to propose a standard to incorporate time-code specific information ?

Going through Transmission metadata fields: Metadata about the field itself: Title ID - a unique identifier (could be the URL, or something that is necessarily unique) - probably need a guide-line to ensure that multiple people don't use the same ID. eg. pad.ma uses a hash of the raw DV video file. Link to Feed Rights - Default rights of feed itself (not necessarily of the video, but of the feed document itself). Image / Logo for the feed (different from thumbnail of the video).

The fields for the videos:

Title Description Keywords / Tags Genres Subtitles - not required. Published - Timestamp - Compulsory Publication Data of Entry. Last Updated - Optional. Related Page - Optional. - Q: Possbible to allow multiple related pages?

Q: Is the genre list really relevant to the kind of films transmission wishes to support? Seems to be more oriented toward fiction..

Thumbnails Link to Video, including possible Torrent link. (one type of link is required.) Credits - Author, Name, Contributor, etc. - can we include a link to page of the various people as well? License - the license of the film . This is currently an optional field - should it be made mandatory, since not specifying license leads to the legal assumption that it is Copyright, All Rights Reserved. Framerate Audio Bitrate Codec - (Q: Do we have a standardization of codec names? A: Yes, there is a standard list of strings to use.) Channels Duration (Container format field is missing?) Size (in Bytes)

(Replace with Link to Example field)

Andy: Since mandatory is only for a parser to define whether it will be valid XML or not, try to keep the rules as loose as possible. Do we make a recommendation to make this field mandatory?

Q: Is there some way to get a fingerprint of the video so that it is possible to identify the same video even across different formats? A: Good question:).

Q: Will be good if you can standardize the names of the main licenses. Is this done? A: Yes, you need to give the URL to the license.