Making the case for FabML

From Fab Lab Wiki - by NMÍ Kvikan
Revision as of 11:00, 26 March 2011 by Anu (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Step 0

RSS of fabmoments. No gimmicks, no add-ons, just plain simple RSS that's served by default by whichever CMS or web framework the lab is using. It's possible to categorise on the aggregator on per-feed (not per-fabmoment) basis, e.g. like the location is handled currently.

Even if this sounds very basic, it would still be a huge step forward in sharing what we make. (naturally, this would first require the documentation tools being there for the local labs, something we can help with on Drupal and Wordpress platforms at least)

Step 1

XML feed with additional, custom-added fields needed for sorting the content on the aggregator. For this, we would have to define some minimal requirements for the feed - what would users expect to be able to search with on the aggregator. So, a custom XML feed format for FabLabs (could be called FabML :). We did actually discuss this with Peter as well some weeks back.

As there are more Fablabs, including the ones less privileged with web access, way to exchange information will become an issue anyway so anything we could define would also help in the rest of the documentation efforts all over. And before storming forward, I'd like to know if anything of the kind exists, has been thought of or tried already?

Based on my Drupal experiments, it's almost the same amount of effort whether I serve RSS with any level of customization or a completely self-defined XML - so it would definitely make sense to continue XML prototyping on the current aggregator. Luke: building XML "feed" = Views XML, reading XML-formatted feeds = Feeds XPath parser (I do intend to log any experiments and conclusions, but only after the Documentator is live and kicking)

Step n (possibly)

moving towards the Semantic Web and more agile information exchange , things like RDF, RESTful APIs etc etc. This would likely benefit from earlier prototyping, as the information requirements can be developed based on user needs that come up during the more initial stages. But I think we're not there yet, with current IT infrastructure across labs.