Summary

On the grounds of the rich software data available in the 101companies project, a Web API should support access to this data in a Linked Data manner. This includes these sorts of data:

• Physical data
  • 101repo folders and files and fragments thereof
  • Resources and dumps derived by 101worker
  • 101worker module I/O behavior and dependencies (based on a dump TBD)
  • 101wiki pages and links on pages
• Primary exploration is based on "conceptual" data
  • Entities (i.e., Language:Java versus wiki page for Language:Java)
  • Namespaces (prefixes) and thus entities per namespace
  • … much of the list above has also physical counterpart …

Bidirectional links are required between these entities:

• Conceptual entities (e.g., languages)
• Primary resources (101repo)
• Derived resources (derived by 101worker)
• Dumps (derived by 101worker)
• 101worker modules possibly in terms of their descriptions
• 101wiki entities and their pages

Some examples of links are these:

• Navigate between primary and derived resources.
• Navigate between primary resources and its fragments.
• Navigate between languages and contributions that use the language.
  • Option 1: as declared on 101wiki
  • Option 2: as evidenced by files in 101repo
• Instead of "languages" above, we also care about technologies, concepts, contributors.
• Navigate between modules and primary/derived resources/dumps.
• Navigate between 101repo (GitHub), 101wiki (real wiki), and 101worker's data view.

Logistics

• The Web API is to be developed in Rails (because 101wiki is already based on Rails).
• Client-side REST-based testing can / should be done in Python (or Ruby).
• The development must supersede the current 101explorer.
• HTML and JSON access is required.

Further reading

• Related presentation by Ralf Lämmel (.pdf)
• Related conference paper by Softlang Team (.html)
• Related MSc thesis by Martin Leiberger (.pdf)
• For the overall "101" vision; see all the papers (.html)