vLib information resources are available in RSS 2.0 format, see http://vlib.mpg.de/vlib-rss-feed.html
What’s the benefit of this? A news stream to hook interest? A huge list of entry points to be filtered and maintained in a user’s own environment?
As items basically consist of a title, a description and a link, crucial information about the vLib resource represented by an RSS 2.0 item may fail to be conveyed.
This may be a mere mapping issue as discussed at https://devtools.mpdl.mpg.de/projects/vlib/wiki/RSS (i.e. map more fields to RSS 2.0 item description) – where we are not taking into account additional atom elements yet (to contain, for example, an html-formatted description), or atom format to contain more detailed data about a resource.
Or we might even consider pointing subscribers to our own interface to a resource rather than to the resource’s original web interface.
The vLib resource interface URL is actually present within items as guid, and, in fact, it is meant to be a permalink – however, certain feed readers appear to prefer a permalink in guid to the URL in item link, that’s why guid isPermaLink is presently set to false.
hm. i think few feed readers will do anything reasonable with two URLs provided for an entry (the link and guid content). so maybe one should have two types of feeds? or duplicate entries in the same feed?
i guess we should go for something like enrich feed description, add vLib resource interface link to description by default (more info about resource…), retain the original web interface URL in item link (so people may get around vLib, and create their own resource link lists directly from the feed).
vLib resource id in item guid is good for (internal) applications, but we may as well do without the complete URL in guid (though full URLs as identifiers are to be considered an advantage – though we have to falsely label them as non-permalinks – ?)
in order to enrich the description layout, I wonder whether we ought to just use some html (create links and line breaks – and leave it to feed readers to deal with them) or risk something like an (alternative) atom:summary – or rather separate formats entirely – ??