Talk:Media rss media group element

From Bjoern Hassler

[edit] Adding version control

There some circumstances, such as off-line caching, distribution scenarios via file sharing, re-use and re-mixing of media objects, where an unique identifier per media:content element may be import.

We suggest three mechanisms to do this: doi / updated / version:

     <media:content 
              url="http://www.foo.com/movie.mov" 
              smn:doi="<doi>"
              smn:updated="<date>"
              smn:version="<string>"
      </media:content>

Ideally these would also be added to the file as metadata. In addition:

smn:md5="<md5sum>"

would be good, to be able to verify the media.

We discuss those elements:

1. smn:doi: While a digital object identifier may be desirable, and it cheap, adding a new doi per (re-)encode across a large collection may build up.
2. smn:updated: Would be a date stamp, that is updated whenever the new file is encoded. There are no disadvantages to this.
3. smn:version: The version could be per encode of the file, or even an encode number on your system, where all encodes are labeled, e.g. with the year "2009/encode number" or similar.
4. smn:md5: Adding an md5 hash is also good to be able to verify the integrity of the file. This adds computational overheads at file creation.

Additional considerations: Do you reflect the version in the url?

url=" ....../142567/myfile.mp3"

Do you reflect the version in the filename?

url="....../142567/myfile_142567.mp3"

WIth some feed readers, if the guid of the feed doesn't change, the record won't be updated. Thus filenames that were once used, need to remain in existence. There are two alternatives:

1. You always keep the same url/filename. This is tricky in terms of versioning.
2. You create redirects where file versions changes. I.e. old urls remain valid, but they are redirected to the new urls. (file share / cache friendly)
3. You have an extension to the guid, and every time files are re-encoded, you increase the guid extebsion in the feed. Thus feed readers show a new item/entry and let you download. However, the old entry becomes orphaned.

Really only the 2nd one is filesharing and caching friendly. (Though we can presumably set http headers carefully, and tell from the headers in case 1 as well, but case 2 is more robust.)

(Footnote: We use case 3 at the moment with audio previews, where an audio file is published first, and the video takes more time for copyright reasons. The guid is "id/audiopreview", which is changed to "id" when the video is published. The website only has one version, but feed readers will update, and show another item when the video becomes available.)