The actionstream plugin uses an all-powerful config.yaml to format output and read input - it governs parsing and data schema.

The schema is semi-normal.  In trying to create a backup/restore functionality for the plugin I found that it is not quite normal enough to reconstruct the whole actionstream from its output without matching the HTML against the actual html_form data in the YAML.  This page documents my ideas around getting the schema normalized to the point that we can do this.

* Problem #1: backwards compatibility with our own plugin.  Any schema changes mean the plugin cannot display old entries from its own table (is this really a problem?  could we make a script to normalize the old data? do we care?)
* Problem #2: cross-compatibility with the MT version... probably not a big issue... while sharing the same roots, the plugins parted ways quite some time ago... our config.yaml is very different than there's and no interest has been expressed in reconciling them.

== Current Schema ==

* identifier - some GUID for the item, compare ATOM id and RSS guid.  Seems fine, very present in the code.
* service - the service this is from... seems reasonable
* url - the "main url" to the item back at the service... tweet link, blog post permalink, etc.  hAtom calls this rel=bookmark.  RSS/ATOM calls this "link".  I would be a fan of changing to "link", but it works as-is.
* title - the title of the item if there is one.  Consistent with RSS/ATOM/hAtom
* description - extended body/text data about the item. Consistent with RSS.  Similar to ATOM/hAtom "summary", but not quite... "description" seems to fit better.
* thumbnail - youtube/flickr/others, URL to thumnail image of item.  This is consistent with [http://search.yahoo.com/mrss mRSS] and seems reasonable.
* by - author name (when author is different from action stream owner, such as youtube favourites/goodreads), rarely used, comparable to RSS/ATOM/hAtom "author", but that should perhaps be reserved for the author of the actionstream item itself? (current usage: author is action item owner, content owner not displayed).
* created_on - action stream item publish date.  Comparable to RSS pubDate and ATOM/hAtom "published"
* modified_on - last update time for item, seldom used, compare ATOM/hAtom "updated"
* artist - musical artist (for last.fm and similar) compare "contributor" (hAudio).  Also, MBIDs and "album"... seems there are two classes of data: the item and the "object".  hAudio solves this for output... keep current artist/album backend schema?
* note - for pownce. compare "description" - these should be normalized
* venue - for events.  Could be hCard for output, seems like there will be little overlap with non-events, this seems fine.
* tweet - for twitter, compare "description" - these should be normalized
* tags - seems reasonable, not currently used in output
* favourite/loved - used in iusethis, which is completely broken in the WP implementation.  Not sure what it's for. <nowiki>[quant,_4, (and loves it),,]</nowiki>
* placeLink/placeName - used for britekite, not sure if there is any intersection with other services we may futurely support... do we need to support service-specific data somehow?