Subject: Atom feed design for a variety of media types

From: "James Abley" <[email-masked]>
Date: Mon, 14 Jan 2008 14:27:04 +0000

Hi,

The background for this request is that my company helps our partners
deliver content on mobile internet platforms. We are trying to guide
our partners into producing a common feed format that can be easily
re-purposed and doesn't require specialist tools to handle.

I'm trying to define a feed format for content which will be
potentially produced by a variety of producers (news agencies, games
companies, audio file producers and video producers as a starting
point). The initial use case is purely for news, games and audio, so
I'm dealing with multiple content types of media items.

Atom is my own preferred choice (interop, tool support, etc) rather
than anything else, so I've been trying to match my gut feel about how
to implement this with what I've been reading in the archives for this
list.

My initial problem - meta-data
-------------------------------------------
I think I can use the Yahoo Media RSS Module for RSS 2.0 [1], which
should cover that. Otherwise, I'd need to introduce something similar
to that module, which covers the shortfall. Or should I be using RDF
or Dublin Core? Any experience or suggestions with this?

Next problem - content expiry
-------------------------------------------
Predominantly I think this is required for news agencies, so that they
have control over what gets displayed downstream. My initial ideas,
seemingly confirmed by the archives, are for one of the following:

1. A separate feed, the semantics of which are understood to indicate
content expiry / deletion.
2. Tombstones.
3. Expiry explicitly indicated on feed items, again with an extension
element / attribute, or RDF or Dublin Core.

I think that the Tombstone discussion is going to go on for a while,
and I'm quite comfortable with the idea of the first choice, unless
anyone violently disagrees.

Final problem (for now!) - editorial control / lead articles
-------------------------------------------------------------------------------
Certain content producers have indicated that they need to be able to
define importance on a feed entry; e.g. the story about the US
election should be treated as the lead story, and the story about
someone's lost dog is the "...and finally..." story that we can put at
the bottom of a page.

I haven't seen anything in core Atom about this, so maybe it's the
extension element, or RDF or Dublin Core route again?

Related subject - having multiple images for an item, with different
semantics on the images; e.g. this one is the image related to the
story subject matter; e.g. picture of Presidential candidate; this one
is the headshot of the columnist that authored the story. For that,
along with the extension element / RDF / Dublin Core options, I have
the added choice of using a (non-official) link relation extension.

<atom:link rel="http://example.com/headshot" src="path/to/person.jpg"
type="image/jpeg" />
<atom:link rel="http://example.com/story" src="path/to/clinton.jpg"
type="image/jpeg" />

This is where I'm least sure of what the right thing to do would be.
James Snell recently blogged about proposing to OSCON a session on
designing Atom extensions. I need it a little earlier than I thought!

Cheers,

James

[1] http://search.yahoo.com/mrss
[2] http://www.snellspace.com/wp/?p=848

---

From: James M Snell <[email-masked]>
Date: Mon, 14 Jan 2008 07:57:27 -0800

> My initial problem - meta-data

I've seen the both the Yahoo and iTunes extensions being used.  I don't 
believe there is any one approach that would be recommended over the others.

> Next problem - content expiry

For the short term, #1 would likely be your best bet as it requires the 
least amount of invention and would be the easiest to migrate over to 
whatever the final tombstone approach becomes.

> Final problem (for now!) - editorial control / lead articles

In Lotus Connections, we use atom:category elements for this.  You could 
do so also, e.g.

   <category scheme="http://example.org/importance" term="lead" />

> <atom:link rel="http://example.com/story" src="path/to/clinton.jpg"

This is an excellent solution.

> designing Atom extensions. I need it a little earlier than I thought!

:-)

- James

---

From: "James Holderness" <[email-masked]>
Date: Mon, 14 Jan 2008 19:34:25 -0000

> re-purposed and doesn't require specialist tools to handle.

When you say "doesn't require specialist tools", does that mean you would 
like the feed to work with a typical feed reader? Or are you only worried 
about generating the feed with a general purpose tool (like say Abdera) but 
expect a specialist client to read the feed?

If the former, I think you're going about this the wrong way. If the latter, 
you can ignore the rest of this message.

> should cover that.

Exactly what kind of metadata do you need? If you just want to assign 
metadata to the feed entries then there's not that much that Yahoo Media 
gives you that isn't already in Atom (author, description, category, etc.). 
If your worry is that you need to include multiple media enclosures with 
each entry and want to provide separate metadata for each enclosure then you 
have much bigger problems.

Support for multiple Atom enclosure links is fairly poor in current feed 
readers, but there is at least some support. Support for Yahoo media:content 
elements in Atom is non-existent (AFAIK). Your best bet for adding metadata 
to multiple enclosure elements would be as sub-elements of a standard 
atom:link element. That still requires a specialist client to view the 
metadata, but at least the media itself might be accessible to a general 
purpose reader.

> Next problem - content expiry

As long as those news agencies are aware that they really have no control 
over what gets displayed downstream. It doesn't matter what option you 
choose, nearly all general purpose feed readers will ignore it. The only 
hope of having any control like this would be with some form of encryption 
and a proprietary client (something like DIVX perhaps).

> Final problem (for now!) - editorial control / lead articles

I would go with a category element as James Snell suggested. That would at 
least have some value in a general purpose feed reader.

> the added choice of using a (non-official) link relation extension.

I don't get what you're trying to do here. Why don't you just include the 
images in the (x)html of the content element, laid out in some way that 
would look good to a regular feed reader. If you need the metadata for use 
in a specialist client, come up with your own microformat (class attributes 
on the img elements). That should make it easy for the client to do a more 
fancy layout with CSS or even extract the images from the markup if 
necessary.

Bottom line: if you want these feeds to be useful (not just barely 
functional) to a typical feed reader you need to be thinking how you can use 
standard Atom elements as much as possible. Extensions should be a last 
resort when all else has failed.

Regards
James

---

From: "James Abley" <[email-masked]>
Date: Mon, 14 Jan 2008 23:43:56 +0000

> you can ignore the rest of this message.

My bad for not being clearer. It's pretty much the latter.

It's a little strange. We have had a variety of clients with their own
custom XML formats that we've imported, some that provide RSS 2.0 plus
their own extension modules and some that don't have an existing feed
and are amenable to our input in terms of how the feed is structured.
For now, the feeds aren't consumed by typical feed readers - mainly
just our importing application (which imports the content and
processes it into a form suitable for display on mobile devices) and
other partners' applications that wish to process the feed.

In order to re-use our importer code-base as much as possible, we'd
like to offer the same Atom-based suggestion to current and future
clients. That has the obvious benefits for my company in that I only
have to write one client using Abdera / suitable Java library and we
can then get away from writing custom importers for each client. It
also has the desirable property that our client ends up with a feed
that should be useful in other contexts, and isn't irrevocably tied to
our solution; i.e. the client doesn't feel locked in.

One of our clients is talking about using this format with all of
their partners in an industry sector, hence my desire to use open
standards, re-use existing extensions and avoid any custom extensions
as much as possible. I think (maybe incorrectly) that it's more likely
to appeal to a wider community within that industry sector if it's
open, standards-based rather than a proprietary format that maps to
our internal binary data structures.

In summary, we already have a client which will process these feeds.
I'm trying to define a suitable format for our upstream partners to
produce.

> have much bigger problems.

Maybe metadata is a bit misleading. I view it as metadata, but it's
really just the attributes of the media entity. For images, this may
be height, width, colour depth, etc. For video, this could be audio
bitrate, video bitrate, frames per second, duration, etc. We could try
extracting that ourselves, or we can rely on the author of the media
entity knowing what it is and setting the corresponding attributes in
the feed.

> metadata, but at least the media itself might be accessible to a general

That's what my current draft looks like, so colour me happy. There are
typically multiple versions of the same media entity, e.g the lost dog
story video;  provided in different formats to ensure good coverage of
target client devices. Alternatively, there may only be a single
version, and we produce lots of different versions as part of the
import process.

> resort when all else has failed.

Thanks for your comments - very useful. I should have made my position clearer.

Cheers,

James

---

From: Peter Keane <[email-masked]>
Date: Mon, 14 Jan 2008 20:41:23 -0600 (CST)

> version, and we produce lots of different versions as part of the

This is the same use case I am facing (digital
image/video/audio/document library to be used in higher ed.). And
figuring out metadata for multiple media entities is the last piece of
the puzzle for using Atom.  I had gone with a custom "microformat" xhtml
to be included in the content for the media but encoding metadata using
classes was getting kludgy.  So...does this seem like a reasonable
approach:

<link rel="http://example.com/thumbnail" 
href="http://example.com/media/123_100.jpg" type="image/jpeg"
length="3452">
   <x:height>120</x:height>
   <x:width>120</x:width>
</link>

<link rel="enclosure" href="http/example.com/media/123.mov"
type="video/quicktime" length="3434343">
   <x:duration>123</x:duration>
   <x:bitrate>128</x:bitrate>
   <x:checksum>e18d8047a12bac8274e018dc70cb7d39</x:checksum>
</link>

<link rel="enclosure" href="http/example.com/media/123.mp3"
type="audio/mpeg" length="34343">
   <x:duration>123</x:duration>
   <x:bitrate>128</x:bitrate>
   <x:channel_mode>stereo<x:channel_mode>
   <x:checksum>2e6e63a97c1cbcd4741489849f7e4ab8</x:checksum>
</link>

This, too, is for a custom application (I am the consumer and publisher) 
but potential for reuse and the desire to create a sane design are highly 
desired.  (I, too, need to attend a James Snell session on creating atom 
extensions!).

-peter keane

daseproject.org

---

From: James M Snell <[email-masked]>
Date: Mon, 14 Jan 2008 21:29:27 -0800

I had been involved in some discussions a while back geared towards 
working on a standard set of media extensions derived from the itunes 
and yahoo media extensions.  Unfortunately, that work never progressed. 
  Such work would certainly not be unwelcome.

- James

Peter Keane wrote:
> [snip]
> but potential for reuse and the desire to create a sane design are 
> highly desired.  (I, too, need to attend a James Snell session on 
> creating atom extensions!).
> 
> -peter keane
> 
> daseproject.org
> 
>

---

From: Peter Keane <[email-masked]>
Date: Mon, 14 Jan 2008 23:48:35 -0600 (CST)

On Mon, 14 Jan 2008, James M Snell wrote:

> I had been involved in some discussions a while back geared towards working 
> on a standard set of media extensions derived from the itunes and yahoo media 
> extensions.  Unfortunately, that work never progressed.  Such work would 
> certainly not be unwelcome.
>
> - James

Absolutely.  It would be a huge boon for the sort of work we are trying to 
do. MIT's OpenCourseWare, ITunes U, etc. are all the rage.  A Media-rich 
Atom standard would be a no-brainer for that area (and with FeedSync or a 
FeedSync-type standard along with it, a very powerful platform indeed).

Any thoughts on how such a process might be re-booted?

-peter

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Wed, 16 Jan 2008 10:08:51 +0000

Peter Keane a écrit :
>> and yahoo media extensions.  Unfortunately, that work never 
>> progressed.  Such work would certainly not be unwelcome.
>>
>> - James
>
> Absolutely.  It would be a huge boon for the sort of work we are 
> trying to do. MIT's OpenCourseWare, ITunes U, etc. are all the rage.  
> A Media-rich Atom standard would be a no-brainer for that area (and 
> with FeedSync or a FeedSync-type standard along with it, a very 
> powerful platform indeed).
>

I concur and I'd join such work if it existed.

- Sylvain

---

From: James M Snell <[email-masked]>
Date: Wed, 16 Jan 2008 07:55:23 -0800

All it would really take are implementors willing to support the 
extensions once they were defined and a group of individuals willing to 
do the work to define them.  I'm willing to help.

- James

---

From: "James Abley" <[email-masked]>
Date: Thu, 17 Jan 2008 00:33:04 +0000

> do the work to define them.  I'm willing to help.

I'm wary of making commitments that I can't keep, having recently had
to drop out of one community due to most of my spare hacking time
being taken up with working at the startup that I'm currently with,
but I'd like to take this forward if possible. Any suggestions for
ways to do that?

James

---

From: James M Snell <[email-masked]>
Date: Wed, 16 Jan 2008 19:32:01 -0800

The best place to start would be to start collecting as many use cases 
as possible from folks who are writing actual code; documenting what 
kinds of information need to be in the feeds and why.

- James

---

From: Peter Keane <[email-masked]>
Date: Wed, 16 Jan 2008 21:46:16 -0600 (CST)

A use-case, if it's of interest: We have an online digital library 
application, which contains images (jpg,png,gif,tiff), also PDFs, audio 
files (mp3,wav), video (mpeg4, etc). It's widely used here at UT Austin, 
mostly for instructional purposes, but also for content-managing media 
rich web sites [0]. It uses Atom extensively for moving data around and 
for archiving collections.

I typically get EXIF data from jpegs, id3v2 medatadata from mp3s, and IPTC
data from images when possible. I can use the content element in Atom to
capture metadata about the primary media file, but it's that metadata that
varies per media file that I need to deal with (height, width, bitrate,
stereo/mono, aspect ratio, md5 hash, etc.) in atom:link.

Yahoo's Media RSS Module [1] seems to do most of what I need, and perhaps
just using that is the best option.  There was a need expressed some time
back for the Atom group to address these media file issues [2] and again
in the current thread.  It strikes me that any of: 1. saying that using
Yahoo Media RSS is a "best practice", 2. "porting" Yahoo Media RSS to a
more Atom-like syntax and implementing that, 3. doing something else
entirely -- would be fine.

I really like the idea of the atom "link" element being the appropriate 
starting point and working on the best set of "rel" values and a set of 
agreed-upon child elements (based on Yahoo Media RSS).  Of course, Yahoo 
Media RSS has the idea of a "media group" (i.e. a set of files that are 
different versions of the same thing) which I really like and which 
should, I think, be handled.  I'm not 100% sure what all needs to be done 
to begin defining extensions, but I would be glad to take a stab at 
"porting" Yahoo Media RSS to an atom-like syntax for others to comment on 
if folks think that'd be a useful exercise.

One more point: ours is a "closed" system in many ways, so it doesn't 
really matter what we do, but time and again I have folks wanting to 
repurpose their materials (usually "podcasting", but other ways as well). 
Being able to share collections externally and/or to ingest collections 
born elsewhere would be a tremendous benefit.

--Peter Keane

[0] http://elucy.org
[1] http://search.yahoo.com/mrss
[2] http://www.imc.org/atom-syntax/mail-archive/msg11813.html

---

From: Peter Keane <[email-masked]>
Date: Wed, 16 Jan 2008 22:05:43 -0600 (CST)

One thing I wanted to add about the use case I described & this effort. 
For me the goal is: 1. to come up with an agreed upon way to record 
metadata about media files, and 2. to define, even if implicitly, when 
a set of media files is appropriately attached to one entry and when each 
of those media files should really have it's own entry (i.e., if you are 
simply recreating the same elements of the atom entry as children of 
atom:link, the media file ought to have its own entry).

As a librarian I have seen these sorts of conversation lead to fascinating 
but never-ending philosophizing [0]. I greatly appreciate the Atom 
communities' track record of deciding what is the "simplest thing that'll 
work" and leaving it at that (plus extensibility, of course).

--peter keane

[0] http://www.loc.gov/cds/FRBR.html

On Wed, 16 Jan 2008, James M Snell wrote:

>
> The best place to start would be to start collecting as many use cases as 
> possible from folks who are writing actual code; documenting what kinds of 
> information need to be in the feeds and why.
>
> - James
>
> James Abley wrote:

---

From: "James Holderness" <[email-masked]>
Date: Thu, 17 Jan 2008 07:54:17 -0000

Peter Keane wrote:
> It strikes me that any of: 1. saying that using

It's hard to recommend the Yahoo module as a best practice when the spec has 
been broken for years, and Yahoo is apparently incapable of fixing it, 
despite having know of the problem for more than 6 months now (at least).

Also, it would nice if whatever you did still worked (albeit with less 
functionality) with clients that weren't aware of your extensions. That 
means using a basic Atom enclosure link as your starting point, and then 
adding any extensions on top of that.

Regards
James

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Thu, 17 Jan 2008 10:25:15 +0000

Peter Keane a écrit :
> application, which contains images (jpg,png,gif,tiff), also PDFs, 
> audio files (mp3,wav), video (mpeg4, etc). It's widely used here at UT 
> Austin, mostly for instructional purposes, but also for 
> content-managing media rich web sites [0]. It uses Atom extensively 
> for moving data around and for archiving collections.
>

I typically use those existing meta-data as well and simply try to map 
them to Dublin Core elements, which has proven to be quite hard 
considering how generic DC can be. I do not try to extend the Atom 
namespace usually but rather re-use an existing one (for instance for 
multimedia resources I often try to use Mpeg7).

I'm not sure however to understand what the atom:link could provide. If 
it was to specify a given taxonomy, why not define it in terms of 
atom:category/@term in a given scheme instead?

- Sylvain

---

From: Peter Keane <[email-masked]>
Date: Thu, 17 Jan 2008 06:39:07 -0600 (CST)

On Thu, 17 Jan 2008, Sylvain Hellegouarch wrote:
>
> I'm not sure however to understand what the atom:link could provide. If it 
> was to specify a given taxonomy, why not define it in terms of 

Actually, I was thinking of using atom:link to capture the bits of 
metadata that would vary per media file.  Ex:

<entry>
...
<link rel="enclosure" href="1234.mp3" type="audio/mpeg">
   <x:channelMode>mono</x:channelMode>
   <x:bitrate>128<x:bitrate>
</link>

<link rel="enclosure" href="1234.mp3" type="audio/wav">
   <x:channelMode>stereo</x:channelMode>
   <x:samplingRate>44.1<x:samplingRate>
</link>

<link rel="http://xxxxx/thumbnail" href="1234.jpg" type="image/jpeg">
   <x:height>120</x:height>
   <x:width>120</x:width>
</link>

</entry>

--peter

---

From: "Eric Lunt" <[email-masked]>
Date: Thu, 17 Jan 2008 06:54:20 -0600

I'd definitely be interested in this as well, and we could update
FeedBurner's namespace translation to help ease the transition between old
and new clients so that even if someone used the new namespace, for example,
we could still generate the appropriate iTunes tags when iTunes comes
calling for the feed. I still think there's a lot of promise in the Media
RSS namespace, but the lack of activity and support around it makes me a
little hesitant to recommend it.

- Eric

---

From: Peter Keane <[email-masked]>
Date: Thu, 17 Jan 2008 09:14:01 -0600 (CST)

Does anyone here know the status of this effort by the w3c:

Comparing Media RSS formats
http://www.w3.org/2005/07/media-and-rss.html

the page was last updated 7/27/2005

--peter keane

---

From: James M Snell <[email-masked]>
Date: Thu, 17 Jan 2008 08:14:45 -0800

It has actually been a while since I've looked at this area so I'm not 
really up to date on the existing markup options beyond Media RSS and 
the itunes extensions.  It would be very helpful if someone could 
provide a brief overview of existing media metadata options, including 
where those options are being used.

- James

---

From: James M Snell <[email-masked]>
Date: Thu, 17 Jan 2008 08:12:03 -0800

+1 on every point.

- James

James Holderness wrote:
> It's hard to recommend the Yahoo module as a best practice when the spec 
> has been broken for years, and Yahoo is apparently incapable of fixing 
> it, despite having know of the problem for more than 6 months now (at 
> least).
>

---

From: James M Snell <[email-masked]>
Date: Thu, 17 Jan 2008 08:21:47 -0800

This is definitely good to hear.

- James

Eric Lunt wrote:
> FeedBurner's namespace translation to help ease the transition between 
> old and new clients so that even if someone used the new namespace, for 
> example, we could still generate the appropriate iTunes tags when iTunes 
> comes calling for the feed. I still think there's a lot of promise in 
> the Media RSS namespace, but the lack of activity and support around it 
> makes me a little hesitant to recommend it.
> 
> - Eric
> 
> On Jan 16, 2008 9:55 AM, James M Snell <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>

---

From: James M Snell <[email-masked]>
Date: Thu, 17 Jan 2008 08:20:08 -0800

FWIW, quite some time ago I had proposed a set of "Atom link extensions" 
that, at the time, failed to get any momentum.  Some details here: 
http://www.snellspace.com/wp/?p=247.

One of the criticisms of that work was that while rfc4287 allowed the 
atom:link element to have child elements, it was not clear how many 
implementations would actually be able to do anything with them. Another 
issue was whether implementations that could get to the extensions 
actually would do anything with them.

- James

Peter Keane wrote:
>> I'm not sure however to understand what the atom:link could provide. 
>> If it was to specify a given taxonomy, why not define it in terms of

---

From: Karl Dubost <[email-masked]>
Date: Fri, 18 Jan 2008 06:38:20 +0900

> Does anyone here know the status of this effort by the w3c:

First of all :) first sentence in the page

    "This is an informal overview by the author(s),
     and not the product of a review by any formal
     W3C group."

So it's not an effort by the W3C

> the page was last updated 7/27/2005

    I did this page when there was discussions about media content in  
atom, to see what was available at this time. If you have more up to  
date information about it maybe I could add it to the page.

Thanks.

--
Karl Dubost - W3C
http://www.w3.org/QA/
Be Strict To Be Cool

---

From: Eric Scheid <[email-masked]>
Date: Fri, 18 Jan 2008 14:21:08 +1100

> actually would do anything with them.

that is pretty much par for the course for *any* extension though, right?

e.

---

From: James M Snell <[email-masked]>
Date: Thu, 17 Jan 2008 20:51:57 -0800

Indeed, which is why I didn't think there was much merit in the argument 
back them either ;-)

- James

---

From: Ryan Parman <[email-masked]>
Date: Thu, 17 Jan 2008 23:28:04 -0800

> http://www.w3.org/2005/07/media-and-rss.html

Even in this document, the wrong namespace is listed for Media RSS  
(the correct form -- and why the spec is broken -- should have a  
trailing slash).

I'm doing some short-term contract work for Y!, completely unrelated  
to RSS/Atom. This very thread (as it pertains to Media RSS) was  
pointed out in an internal RSS mailing list today, with no response  
from the people who are supposed to be involved in this stuff. Either  
they're on vacation, or they've essentially checked-out from the Media  
RSS world. Heck, even Y! News uses the wrong namespace URL (and they  
even added an element or two that doesn't exist in the spec).

Either way, it might be time for a responsible community member to  
fork version 1.1.2 of the spec, clean up the document, put together  
some unit tests for implementors, and add some sort of formal process  
around it so that the world can move on without Y!'s help (or lack  
thereof).

=========================================
Ryan Parman
Creator and Co-Developer
SimplePie

http://simplepie.org

---

From: "James Holderness" <[email-masked]>
Date: Fri, 18 Jan 2008 08:27:32 -0000

Ryan Parman wrote:
> Even in this document, the wrong namespace is listed for Media RSS  (the 
> correct form -- and why the spec is broken -- should have a  trailing 
> slash).

The itunes namespace is wrong too (they had their own little namespace 
screwup for a while). It's all very funny until you have to try and do 
productive work with this rubbish.

Regards
James

---

From: "James Holderness" <[email-masked]>
Date: Fri, 18 Jan 2008 08:52:10 -0000

> that is pretty much par for the course for *any* extension though, right?

Sure, but if you can't find anyone that intends to use your extension (and 
you need both clients and servers), you have to ask yourself why you're 
bothering to design it in the first place.

Not that I'm saying that's the case for media extensions. I just don't think 
you should underestimate the importance of the question: will anyone use 
this?

Regards
James

---

From: Karl Dubost <[email-masked]>
Date: Fri, 18 Jan 2008 18:51:46 +0900

> (the correct form -- and why the spec is broken -- should have a  

I will be happy to modify it if someone gives me the good values :)  
and point out other mistakes.

Thanks

--
Karl Dubost - W3C
http://www.w3.org/QA/
Be Strict To Be Cool

---

From: Karl Dubost <[email-masked]>
Date: Fri, 18 Jan 2008 18:58:12 +0900

> (the correct form -- and why the spec is broken -- should have a  

As the spec right now describe them

* Apple - Last Change: no date :/
http://www.apple.com/itunes/store/podcaststechspecs.html#rss
<rss xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"  
version="2.0">

* Yahoo - Last Change: 2005-10-22 ?
http://search.yahoo.com/mrss
<rss version="2.0" xmlns:media="http://search.yahoo.com/mrss">

--
Karl Dubost - W3C
http://www.w3.org/QA/
Be Strict To Be Cool

---

From: Peter Keane <[email-masked]>
Date: Tue, 22 Jan 2008 00:34:32 -0600 (CST)

In taking a look back over the archives, I see that a good bit or 
discussion around links & link extension has already place [0], which I 
found enlightening (and I am happy to back away from rehashing old 
arguments if that all this ends up being).

In the interest of putting the "what" before the "how", the goals here, as 
I understand it, would be to figure out a way to:

1. provide a way to add metadata to a particular atom:link

2. provide a way to group a set of links and/or to establish a 
relationship between links that appear in a single atom:entry and possibly 
to "type" those relationships

and the means at our disposal:

1. the "rel" attribute of atom:link

2. new extension attributes of atom:link

3. child elements of atom link (and attributes on those elements).

By sticking to those goals & means, I suspect you cover most use cases (at 
least ones that have at hand and/or am aware of), AND clients that DON'T 
implement such an extension shouldn't be hampered.

The one bit of "how" I'd like to see (and this, I realize, may not be a 
majority opinion) would be to have every media entity have it's own 
atom:link, and not be made a child of another atom:link or made part of an 
enumerated, space-delimited list in an atom:link attribute. I.e., I would 
hope that the relationships/groups could be expressed as metadata "about" 
a link.  (The challenge, of course, is to figure out a way to say "this is 
related to that" without identifying the "that" in the statement).  James 
Snell's Atom Link Extension ID used a "group" attribute on atom:link with 
a case-insensitive opaque text string identifying the group.  One would 
them need to rely on the type or rel attributes to discover the media 
entities "role" in that group. Not bad, I think.

Grouping/relationships is the trickiest bit. Not as difficult, would be to 
come up with the list of metadata attributes that might be used with a 
link and figure out if they should be attributes on atom:link or children. 
If children (my preference), you could keep them fairly abstract and allow 
for an "open" set of possible values, e.g.:

<link ...>
   <x:hash type="md5">391ea33cbe3a052e6b247c7b943d1a73</hash>
</link>

OR even:

<link ....>
   <x:format type="height" unit="px">128</format>
   <x:format type="channelMode">stereo</format>
</link>

--Peter Keane

[0] http://www.imc.org/atom-syntax/mail-archive/msg17378.html

---

From: "James Holderness" <[email-masked]>
Date: Wed, 23 Jan 2008 21:15:34 -0000

> <rss xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd" 

I believe that is correct.

> <rss version="2.0" xmlns:media="http://search.yahoo.com/mrss">

That is what the current spec says, but that's not correct. There's an 
official acknowledgement of the mistake here:

http://tech.groups.yahoo.com/group/rss-media/message/1008

Regards
James

---

From: Ryan Parman <[email-masked]>
Date: Sat, 26 Jan 2008 01:48:16 -0800

Correct. David Hall is no longer with Yahoo, and charge over the spec  
has fallen to Jeremy Zadowny. Unfortunately, Jeremy has pretty much  
ignored all requests to fix the spec, so we've got past and present  
versions of the spec with different namespaces.

Yay.

http://simplepie.org

On Jan 23, 2008, at 1:15 PM, James Holderness wrote:

> That is what the current spec says, but that's not correct. There's  
> an official acknowledgement of the mistake here:
>

---

From: James M Snell <[email-masked]>
Date: Sat, 26 Jan 2008 11:23:59 -0800

Ok, not a good situation.  Like I said before, all it really takes to 
get something started here is enough interest from a community of folks 
willing to do the work and implement support.  Assuming we have that, we 
need to start documenting some requirements.

Grouping:

   The ability to group alternative representations of the same content.
   For instance, video may be encoded as wmv, mov, mpg, etc. We need
   the ability to specify a single default representation

Generic content metadata:

   Every piece of content has general metadata applicable to all
   alternate representations.  These include title, description,
   rating, keywords, categorization, copyright, license, credits,
   captioning, lyrics, distribution restrictions, etc.

Media specific metadata:

   Each media resource has metadata specific to the media type.  We need
   the ability to express the appropriate metadata for each resource.

   This metadata may vary across alternative representations of the same
   content.

   These include things like the url, file size, type, medium, bit rate,
   frame rate, sampling rate, channels, duration, display dimensions,
   language, hash, software,

Previews:

   The ability to specify a content preview such as a thumbnail, a
   shortened video snippet, a transcript, etc.  Previews may be offered
   in multiple formats.

If there's anything missing from this, please respond and help fill in 
the gaps.

Once we have the requirements documented, we might as well start 
knocking around a straw man...

<feed xmlns="http://www.w3.org/2005/Atom">
   ...
   <entry>
     <id>tag:example.org,2008:/shows</id>
     <title>My Dog's Wedding</title>
     <updated>2008-12-12T12:12:12Z</updated>
     <published>2008-12-12T12:12:12Z</published>
     <x:expires>2007-12-13T12:12:12Z</x:expires>
     <author>
       <name>James</name>
     </author>
     <summary>My dog got married the other day</summary>
     <category scheme="http://example.org/rating/simple"
               term="nonadult" />
     <category scheme="http://example.org/rating/mpaa"
               term="pg" />
     <category scheme="http://example.org/keywords"
               term="dog" />
     <category scheme="http://example.org/keywords"
               term="wedding" />
     <category scheme="http://example.org/category"
               term="videos/personal/events/weddings/dog" />
     <category scheme="http://example.org/restriction/country/allow"
               term="au us" />
     <category scheme="http://example.org/restriction/country/deny"
               term="ca fr" />
     <rights>Copyright (c) 2008 James</right>
     <link rel="license"
           href="http://www.creativecommons.org/licenses/by-nc/1.0" />
     <x:person scheme="http://example.org/roles" term="director">
       <name>Linda</name>
     </x:person>
     <x:person scheme="http://example.org/roles" term="cameraoperator"
       <name>Joe</name>
     </x:person>
     <x:person  scheme="http://example.org/roles" term="actor">
       <name>The Dog</name>
     </x:person>
     <x:text type="html"
             start="00:00:02.000"
             end="00:00:10.000">&lt;i&gt;...&lt;/i&gt;</x:text>
     <x:text type="html"
             start="00:00:15.000"
             end="00:01:00.000">&lt;i&gt;...&lt;/i&gt;</x:text>
     <content src="#mpeg type="video/quicktime" />
     <link x:id="mov"
           rel="enclosure"
           type="video/quicktime"
           title="Dog's Wedding (quicktime)"
           size="1234567890"
           href="dogwedding.mov">
       <x:hash algorithm="http://www.w3.org/2001/04/xmldsig-more#md5">
         ...
       </x:hash>
       <x:bitrate>...</x:bitrate>
       <x:framerate>...</x:framerate>
       ...
     </link>
     <link x:id="mpeg"
           rel="enclosure"
           type="video/mp4"
           title="Dog's Wedding (mpeg)"
           size="1234567890"
           href="dogwedding.mpeg">
       <x:hash algorithm="http://www.w3.org/2001/04/xmldsig-more#md5">
         ...
       </x:hash>
       <x:bitrate>...</x:bitrate>
       <x:framerate>...</x:framerate>
       ...
     </link>
     <link rel="http://example.org/preview"
           type="video/mp4"
           title="Preview of the Dog's Wedding (mpeg)"
           size="12345"
           href="dogwedding_preview.mpeg">
       <x:hash algorithm="http://www.w3.org/2001/04/xmldsig-more#md5">
         ...
       </x:hash>
       <x:bitrate>...</x:bitrate>
       <x:framerate>...</x:framerate>
       ...
     </link>
     <link rel="http://example.org/preview"
           type="image/jpg"
           title="Screencap from the wedding"
           size="12345"
           href="dogwedding1.jpg">
       <x:hash algorithm="http://www.w3.org/2001/04/xmldsig-more#md5">
         ...
       </x:hash>
     </link>
     <link rel="http://example.org/preview"
           type="image/jpg"
           title="Screencap from the wedding"
           size="12345"
           href="dogwedding2.jpg">
       <x:hash algorithm="http://www.w3.org/2001/04/xmldsig-more#md5">
         ...
       </x:hash>
     </link>
   </entry>
</feed>

Is this better or worse than the yahoo/itunes approaches?  Why?  Does it 
make more sense to use a more iterative approach building from either 
the yahoo or itunes schemas?  What are the other possible approaches?

- James

---

From: "James Holderness" <[email-masked]>
Date: Sat, 26 Jan 2008 20:35:47 -0000

James M Snell wrote:
> Ok, not a good situation.  Like I said before, all it really takes to get 
> something started here is enough interest from a community of folks 
> willing to do the work and implement support.

For the record, I'm not interested in supporting anything like this at the 
moment. My only interest is in making sure that whatever you do doesn't 
render the feed useless to people that don't support the extension.

>     <category scheme="http://example.org/restriction/country/deny"

I'm not sure these are a good fit for the category element. All the other 
examples make sense as category elements without the client knowing anything 
about the scheme.

>     <x:person scheme="http://example.org/roles" term="director">

Any reason why these can't be atom:contributor elements, possibly with an 
x:role attribute or sub-element? Would be more useful to clients not 
supporting the extension and I don't think it would be an inappropriate use 
of atom:contributor.

>     <content src="#mpeg type="video/quicktime" />

That doesn't look legal to me. Surely the IRI reference in the src attribute 
must be dereferenceable? Section 4.1.3.2 of RFC4287: "Atom Processors MAY 
use the IRI to retrieve the content". How does one retrieve content from a 
fragment reference?

> Is this better or worse than the yahoo/itunes approaches?  Why?

Looks better so far. Less reinvention of core elements.

> What are the other possible approaches?

As a client developer, I'd want to ask what metadata might be useful to 
clients first and foremost. Come up with some use cases that amount to more 
than just "have metadata - must publish".

Regards
James

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Sat, 26 Jan 2008 23:13:02 +0000

>
> As a client developer, I'd want to ask what metadata might be useful 
> to clients first and foremost. Come up with some use cases that amount 
> to more than just "have metadata - must publish".

It seems to me that it's one of those potential edge cases where we may 
end up arguing ad libitum without reaching an agreement because not 
everyone uses the Atom format with the same expectation. Atom may have 
come from the blogging world but it's pretty clear that it gradually 
becomes the de facto envelop format for any kind of exchange.

Personally I'm not sure whether or not this thread is about "extending 
the atom vocabulary with common metadata about media resources in order 
to enrich Atom" or "defining developers' best practices for inlining 
metadata with their own namespace in an Atom document".

The former point is quite interesting to me since we could capitalize on 
Atom being seen as a clean and versatile standard and propel the next 
media metadata storage and exchange format with it.The latter point 
seems simply a case of using atom:content with an appropriate media-type.

However if we decide to extend the atom vocabulary like Yahoo did with 
Media-RSS, we ought to actually discuss first with the main players in 
the field today (Apple, Microsoft, Xiph, EXIF, etc.) in order to define 
the minimal relevant set of metadata for common media formats. In some 
way maybe should we expand on the discussion taking place at the 
microformats wiki [1].

- Sylvain

[1] http://microformats.org/wiki/media-metadata-examples

---

From: James M Snell <[email-masked]>
Date: Sat, 26 Jan 2008 18:59:14 -0800

James Holderness wrote:
>> get something started here is enough interest from a community of 
>> folks willing to do the work and implement support.
> 
> For the record, I'm not interested in supporting anything like this at 
> the moment. My only interest is in making sure that whatever you do 
> doesn't render the feed useless to people that don't support the extension.
> 

I'm not convinced that there are very many implementers at all who are 
going to be interested.

> I'm not sure these are a good fit for the category element. All the 
> other examples make sense as category elements without the client 
> knowing anything about the scheme.
> 

+1. it felt odd when I typed it also; but this is a strawman and needs 
to be kicked around a bit.  Are these really going to be necessary, anyway?

> Any reason why these can't be atom:contributor elements, possibly with 
> an x:role attribute or sub-element? Would be more useful to clients not 
> supporting the extension and I don't think it would be an inappropriate 
> use of atom:contributor.
> 

Right. I was thinking the same thing.

> That doesn't look legal to me. Surely the IRI reference in the src 
> attribute must be dereferenceable? Section 4.1.3.2 of RFC4287: "Atom 
> Processors MAY use the IRI to retrieve the content". How does one 
> retrieve content from a fragment reference?
> 

It is dereferencable... just not in the way most implementations would 
likely expect.  :-)  Anyway, the main point is that given a set of links 
with a given rel (e.g. "enclosure") how do we identify which is the 
"primary" or "default" representation?

> Looks better so far. Less reinvention of core elements.

Yeah, that was the main goal.

> clients first and foremost. Come up with some use cases that amount to 
> more than just "have metadata - must publish".
> 

Heh... ok. As a client developer, what metadata might be useful to you? :-)

- James

---

From: Eric Scheid <[email-masked]>
Date: Sun, 27 Jan 2008 18:19:39 +1100

> supporting the extension and I don't think it would be an inappropriate use

hmm .. in drafting RFC 4287 did we disallow the following construct:

    <contributor>
        <name>Linda</name>
        <category scheme="http://example.org/roles" term="director " />
    </contributor>

(sidenote: if this is illegal in Atom 1.0 (RFC 4287), would this be
something that would require a new version to introduce (eg. Atom 1.1) with
corresponding tweaking of the xmlns:atom?)

e.

---

From: Eric Scheid <[email-masked]>
Date: Sun, 27 Jan 2008 18:12:38 +1100

> examples make sense as category elements without the client knowing anything

also, are you (James) implying a space delimited semantic in the @terms?

is this:
    <category 
        scheme="http://example.org/restriction/country/allow"
        term="au us"
        />

the same as:
    <category 
        scheme="http://example.org/restriction/country/allow"
        term="us au"
        />

e.

---

From: James M Snell <[email-masked]>
Date: Sun, 27 Jan 2008 00:39:38 -0800

I'm not implying or suggesting anything.  It's just a strawman intended 
to help stimulate discussion about what The Right Way To Do It should be.

- James

---

From: "James Holderness" <[email-masked]>
Date: Sun, 27 Jan 2008 09:57:06 -0000

James M Snell wrote:
> +1. it felt odd when I typed it also; but this is a strawman and needs to 
> be kicked around a bit.  Are these really going to be necessary, anyway?

Well either those values are informative (don't bother trying to download 
this link if you're in France since it's not going to work); or they're 
meant to be a cheap form of DRM (you MUST NOT download this link if you're 
from France or the RIAA will try and have you arrested).

In the former case the values can't be trusted (and the client probably 
won't know where it is anyway), so it's easiest to just download the link 
anyway and see what works. The latter case is unenforceable so it's 
pointless. So unless I'm missing something, I don't see the need.

> likely expect.  :-)

RFC3986: "When a same-document reference is dereferenced for a retrieval 
action [...] a dereference should not result in a new retrieval action."

So what exactly does one do with such a link? How do you get back a 
quick-time video from that feed without performing a new retrieval action? I 
may be missing something but I don't think that's defined. If it's going to 
break existing implementations that aren't doing anything wrong, then I 
think you should avoid it.

> Anyway, the main point is that given a set of links with a given rel (e.g. 
> "enclosure") how do we identify which is the "primary" or "default" 
> representation?

I understand the intention - I just think you need to come up with another 
way of doing that.

> Heh... ok. As a client developer, what metadata might be useful to you? 

None actually. But I don't do anything fancy with enclosures. All I really 
need is a well-written title attribute, so if I display a list of enclosures 
to the user, they can make an informed decision about which ones they might 
want to download.

If I *was* doing something fancy with enclosures (like some kind of download 
manager), there are probably a number of things I might find useful, but 
stuff like sampling rate and color depth would not be on that list.

Now I'm sure there are other use-cases that might benefit from other 
metadata, but you really need to find people that actually intend to do 
something with this stuff before you try and lock down what it will be. So 
far the only concrete use-case I've heard here was for some form of 
proprietary data exchange, and frankly you might as well use a proprietary 
extension for that (actually I don't even see the point of using Atom for 
that).

Regards
James

---

From: "James Holderness" <[email-masked]>
Date: Sun, 27 Jan 2008 10:52:05 -0000

Sylvain Hellegouarch wrote:
> Atom may have come from the blogging world but it's pretty clear that it 
> gradually becomes the de facto envelop format for any kind of exchange.

The question is why? I don't see much benefit in using Atom over some 
proprietary form of XML (but plenty of disadvantages) unless you 
specifically intend the data to be readable in a typical, blog-reading, Atom 
client as well.

I suspect there's a lot of cargo-cult engineering behind many uses of Atom 
outside the blogging world. Just because you can wrap your data in an Atom 
envelope, that doesn't mean you should.

> Media-RSS, we ought to actually discuss first with the main players in the 
> field today (Apple, Microsoft, Xiph, EXIF, etc.) in order to define the 
> minimal relevant set of metadata for common media formats.

We're back to the use-case of "have metadata - must publish". Why? Who wants 
that metadata? What for?

Regards
James

---

From: Peter Keane <[email-masked]>
Date: Sun, 27 Jan 2008 12:11:36 -0600 (CST)

> -sereniditous re-use opportunities (e.g. "let's make a podcast of this 
> search...")

s/sereniditous/serendipitous/

-pk

---

From: Peter Keane <[email-masked]>
Date: Sun, 27 Jan 2008 12:07:41 -0600 (CST)

On Sun, 27 Jan 2008, James Holderness wrote:

> proprietary form of XML (but plenty of disadvantages) unless you specifically 
> intend the data to be readable in a typical, blog-reading, Atom client as 
> well.
>

Having built a heavily-used (here at UT Austin) CMS/DAM with Atom as the 
standard internal XML format, I have found all kinds of benefits (many of 
which I could've predicted, some I couldn't):

-tool/library support
-feed validator that allows me to sanity-check all sorts of internal 
operations
-"introspecting" internal application processes w/ nothing more than 
Firefox
-ability to "subscribe" to internal processes (including highly 
configurable search results) with a news reader/live bookmarks, etc.
-sereniditous re-use opportunities (e.g. "let's make a podcast of this 
search...")
-lightweight integration with MANY other systems of which all I need to 
ask is: "parse and Atom feed"

to enumerate just a few.

Thus, this talk of a better/enhanced mechanism for media description is of 
great interest, and I have high hopes that some consensus s=can be 
reached.

--peter keane

---

From: Karl Dubost <[email-masked]>
Date: Mon, 28 Jan 2008 09:46:57 +0900

Le 27 janv. 2008 à 08:13, Sylvain Hellegouarch a écrit :
> However if we decide to extend the atom vocabulary like Yahoo did  
> with Media-RSS, we ought to actually discuss first with the main  
> players in the field today (Apple, Microsoft, Xiph, EXIF, etc.) in  
> order to define the minimal relevant set of metadata for common  
> media formats.

Just for information, there has been work done also by a [W3C  
incubator][1] group on [Multimedia Vocabularies][2]. It gives an  
overview of the existing formats and their associated metadata. It's  
quite cool.

# 1. Introduction

     * 1.1 Declaration of Namespaces
     * 1.2 Related Pages

# 2. Types of Multimedia Metadata
# 3. Existing Multimedia Metadata Formats

     * 3.1 Multimedia Metadata Formats For Describing Still Images
     * 3.2 Multimedia Metadata Formats For Describing Audio Content
     * 3.3 Multimedia Metadata Formats For Describing Audio-Visual  
Content
     * 3.4 Multimedia Metadata Formats For Describing Multimedia  
Presentations
     * 3.5 Multimedia Metadata Formats For Describing Specific Domains  
Or Workflows
     * 3.6 Other Multimedia Metadata Related Formats

[1]: http://www.w3.org/2005/Incubator/
[2]: http://www.w3.org/2005/Incubator/mmsem/XGR-vocabularies/

--
Karl Dubost - W3C
http://www.w3.org/QA/
Be Strict To Be Cool

---

From: "James Holderness" <[email-masked]>
Date: Mon, 28 Jan 2008 11:29:02 -0000

Peter Keane wrote:
>> specifically intend the data to be readable in a typical, blog-reading, 
>> Atom client as well.
>

It seems to me you'd get the same kind of benefits from plain old XML.

> -sereniditous re-use opportunities (e.g. "let's make a podcast of this 

Knowing what you know now, would you list these as reasons for choosing Atom 
in a future project along the same line? If so, you're designing a system 
that you specifically intend to be readable in a typical, blog-reading, Atom 
client - and I've already said that may be a good reason to choose Atom.

The fact that you may not have predicted these benefits in your last project 
is no reason to choose Atom blindly for future projects, hoping that you 
might just get some other unpredicted benefits. Atom isn't magic.

It worked well on your current system for specific reasons. That doesn't 
necessarily make it a good envelope format for any kind of exchange. If 
you're going to use it, know why you're using it.

Regards
James

---

From: Peter Keane <[email-masked]>
Date: Mon, 28 Jan 2008 10:31:11 -0600 (CST)

> It seems to me you'd get the same kind of benefits from plain old XML.

Yes, but will the 101 folks that choose to use the "feeds" made available 
in my app by way of lightweight REST-based web services?  How about when 
my design choices propagate to all kinds of applications (many of the 
quick & dirty variety) that I will never even be aware of.

> client - and I've already said that may be a good reason to choose Atom.

The system is designed to use the richer metadata that I include within 
the atom:content element and encoded as simple xhtml definition lists. 
Just so happens it looks real nice in a feed reader.  But my app will be 
doing more with that information.  And thanks to GRDDL & RDF/a should 
provide opportunites for MORE benefits (note that the "cost" here -- using 
xhtml -- was zero. Just following good design principles).

> might just get some other unpredicted benefits. Atom isn't magic.

Perhaps, but it may be surprising to some how well the Atom model maps to 
current use scenarios all over the place.  Maybe higher ed is unique in 
that way, but folks sure seem do have a lot of stuff that fits.

Qouting Tim Bray in "Don't Invent XML Languages" [0]:

"Suppose you think of your data as a list of, well, anything: stock prices 
or workflow steps or cake ingredients or sports statistics. Atom might be 
for you. Suppose the things in the list ought to have human-readable 
labels and have to carry a timestamp and might be re-aggregated into other 
lists. Atom is almost certainly what you need. And for a data format that 
didn't exist a year ago, there's a whole great big butt-load of software 
that understands it."

> you're going to use it, know why you're using it.

As Roy F. says: "Engineer for serendipity" [1]

Note that I don't come to this conclusion w/o a bit of hand-wringing.[2]

--peter keane

> James

[0] http://www.tbray.org/ongoing/When/200x/2006/01/08/No-New-XML-Languages
[1] http://tech.groups.yahoo.com/group/rest-discuss/message/8343
[2] http://blogs.law.harvard.edu/pkeane/2007/10/29/more-on-why-use-atomatompub/

---

From: "Kyle Marvin" <[email-masked]>
Date: Mon, 28 Jan 2008 15:11:42 -0600

On Jan 27, 2008 4:52 AM, James Holderness <[email-masked]> wrote:

> Atom

Hi James,

Here's my view from the trenches...

There are significant benefits to having normalized metadata with
well-understood semantics across a wide variety of types of data.   At
Google, we've been using Atom + AtomPub as the foundation of the Google Data
APIs for almost two years now; the first such API (for Google Calendar)
launched in April 2006 and Atom+AtomPub is now the baseline API model for
Blogger, several media-oriented services (ex Picasa and YouTube) as well as
for a variety of other Google services (Google Calendar, Google Base, Google
Apps Provisioning, ...).

A few examples of where normalized metadata is of benefit:

- having a guid (atom:id) that lets you uniquely identify a resource and
easily correlate it with the same resource received indirectly through
different routes or at different points in time.

- having a timestamp (atom:updated) that lets you identify the last time a
resource changed and possibly tell if the version you have locally is
up-to-date with a remotely managed version of the same resource.

- the ability to get a list (atom:feed) of such resources to perform
correlation and up-to-date checks w/out requiring a large number of HTTP
operations (i.e. GETs on individual resources)

- a set of conventions for both where and how to interact with the resource
(atom:link), such as how to modify or delete it (rel="edit"), how to find an
html-viewable version (rel="alternate"), how to add new resources to a
resource set, etc.

- a model for how to discover and use resource sets (Atom introspection)

You get all of the above benefits no matter what the actual "data type"
associated with the resource is, i.e. whether it's a blog entry, a photo, a
video, a calendar event, a provisioned user, ...    It's also worth noting
that while all the above metadata was created to enable syndication-oriented
use cases, the applicability of much of the metadata goes beyond that
specific use case.

> envelope, that doesn't mean you should.

I think looking at this only from the perspective of Atom syntax vs a custom
XML grammar is perhaps too narrow of a view.  Certainly, there may be
aspects of the syntax that are less of a good fit for certain types of data
and also some additional conventions that need to be developed (as discussed
on this list).   On the whole, the benefits you get from using a metadata
syntax with well-defined and standardized semantics (Atom) and also an
associated well-defined and standardized HTTP-based interaction model
(AtomPub) significantly outweighs the drawbacks, as least that has been our
experience over the year and a half of exposing data for a variety of
different Google services using Atom and AtomPub.

Prior to centering on Atom+AtomPub, I'd probably characterize our API
strategy for different services as fairly ad hoc and diverse;  Given this, I
don't believe we'd ever have been able to launch the quantity of services we
have in the last year and half if we hadn't chosen a common approach that
created leverage and the ability to roll them out while only requiring
incremental API design and domain-specific customization based upon the type
of resource(s) being exposed.

More importantly, picking a common approach (both in syntax and interaction
style) means that external client developers can leverage common tools (many
now in open source form, like Abdera) and knowledge across multiple
Atom/AtomPub-based Google services that would never have been possible
before if we'd chosen a more ad hoc API strategy for each individual
service.

With the specs now done and more high-quality open source implementations of
Atom/AtomPub becoming available, I'm optimistic that others will leverage
the same benefits that we've seen with GData (both for exposing
resource-oriented services and for consuming them).

> the

These questions might possibly be a red herring.  The interesting question
is who wants the *data* and what are the use cases for it.  We see a wide
variety of answers to that question for our APIs: desktop apps,
browser-based apps, mobile apps,  syndication, publishers, aggregators,
...

The real question w/ respect to metadata is whether there are benefits to
having standardized conventions for metadata across data types and
associated web-friendly conventions for how you interact with both the
metadata and the data.  Most importantly, do such conventions contribute
positively to the wide variety of use cases for the data in ways that go
beyond blogging and syndication?  My take on the answer to that: Absolutely!

Cheers!

-- Kyle

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Thu, 31 Jan 2008 20:17:56 +0000

It's an interesting resource for sure and even more the fact that it is 
a W3C initiative however it appears after  (quickly I admit) browsing 
the WG pages that they don't recommend a set of standard metadata to use.

This is a great directory of resources around media metadata nonetheless.

- Sylvain

Karl Dubost a écrit :
>> order to define the minimal relevant set of metadata for common media 
>> formats.
>
>     * 3.3 Multimedia Metadata Formats For Describing Audio-Visual Content