Making the case for FabML
- Fablabs (in the developed countries with abundant web connectivity) are currently using a range of (open source) CMS software (such as Wordpress, MediaWiki or Drupal) for their web presence and project / "making of" documentation.
- Current state of documentation in less web-enabled labs = ?
- Centralized one-size fits all solution is not a realistic goal, considering the very distributed nature of the Fablab network
- Existing open source hardware / maker project documentation hubs (e.g. Thingiverse, Instructables) might not be a viable solution either:
- they are run by external, commercial entities (which despite best intentions might become an issue in the longer run)
- they are not offered as open source platforms that can be installed and configured on independent servers - full customization to Fablab needs is not possible (e.g. localization and “business process” (such as visitor logging) needs cannot be addressed)
- outsourcing documentation to external platforms does not serve the needs of the less web-enabled Fablabs
Defining an information interchange format enabling different Fablabs sharing their documentation regardless documentation system used at an individual lab.
XML (eXtensible Markup Language) is, as the name suggest, an extensible way to mark up your data for machine-readability for data storage and transport.
“FabML” would be an XML definition tailored for Fablab project documentation needs - including things such as controlled vocabularies for machines and materials needed to complete a project in order to allow global searchability and specifying and formalizing other aspects of manufacturing (which will undoubtedly become more obvious as the project proceeds)
As widely supported data exchange format, CMS tools currently in use at Fablabs can be customized relatively easily to produce XML output. It should be relatively straightforward to design (“appropriate computing”) tools to function with this kind of data interchange format for the less web-enabled Fablabs. (Project data synchronization to/from more global resources with limited internet connectivity remains an important issue to be resolved)
XML feeds consisting individual labs' projects can be collected to (de)centralized repository where they can be searched and redistributed - although the proposal does not as such dictate existence of single, global repository. In fact, existence of multiple local repositories and direct peer-to-peer sharing of projects might be another likely outcome. (as might be information exchange via other means than XML in the future - see below)
Simple XML format specifying the minimal information needs as well as tools to output and store the project information are being prototyped (sneak peek available soon)
(to be rewritten)
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)
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.