Hello all,
I had a discussion with Alison about the media module recently, and we
talked about a story for media syndication that i'd like to air here.
I am also working with the Dean Media Team (http;//deanmediateam.com/),
which is coordinating creative talent to produce content in a variety
of forms (videos, signs, business cards, and so on).
At the moment, i see myself as the bridge between H4D and DMT; i don't
know of anyone else who's deeply connected to both projects. There's
a convergence we're approaching that could either turn into a conflict
or into a nice synergy, and i see my role as trying to help things work
out smoothly.
With the Dean Media Team, i'm developing a database to gather URLs to
the media, with two main functions: (a) to enable people to find
relevant media in formats and at mirrors that work for them, and (b) to
give people a place to work collaboratively on media projects.
(You may have seen the rough SQL schema i posted earlier on this list.)
Those two parts -- metadata and collaboration -- constitute the
technical work for the DMT. The metadata half will store things like
category keywords, file formats, sizes, bitrates, and URLs to media.
Sound familiar? That is just what we were talking about building for
the media module. So we can save ourselves a lot of work by using this
metadata database. (In fact, duplicating this work would probably
generate harmful confusion.)
It seems to me that the DMT picture consists of metadata and collaboration,
while the H4D picture for media is about metadata and syndication. The
metadata piece is the common part.
The interesting conclusion is that we don't really need to build anything
special in order to syndicate media. I propose that we just use the
existing article syndication functionality. What the DMT database will
give us is a persistent URL to use to refer to media items, so viewers
can go to that URL and find an appropriate format and mirror. Once we
have persistent URLs, then all you need to do to syndicate a media item
is to simply post the URL of the media item in the text of an article.
Then any stuff we do for articles (syndication, rating, etc.) will also
apply to media posts, for free.
I like this solution because:
(a) It avoids conflicts between two projects trying to do the
same thing in different ways.
(b) It decouples the two parts: the metadata part doesn't depend
on the syndication part, because it's only about having a
persistent URL. And the syndication part doesn't depend on
the metadata part, because you can post a URL to anywhere in
your article. If people decide not to use DMT for whatever
reason, no problem -- they can still post URLs to their content,
regardless of where they decide to put it.
(c) It's the least complicated.
(d) It's the least work.
Note that i'm not declaring any policy on hosting media content here.
I think it's important to leave that flexible ("i don't care how you
post it, just give me a URL"). People will want to host their media
in ways that are convenient to them because it may be hard to move
around big files, etc. They can syndicate any URL they want -- if it's
a link to a node on the DMT site, then they get the benefits of metadata,
collaboration, and a level of indirection in front of a list of mirrors;
if it's just direct link to a media file, that will still work, they
just won't get the added benefits of a metadata repository and won't
be able to move the file.
I'd be grateful for your feedback on this plan.
Thanks!
-- ?!ng
