Skip to content
This repository has been archived by the owner on Jun 16, 2024. It is now read-only.

Latest commit

 

History

History
107 lines (90 loc) · 6.05 KB

tmp_Wikibase-Frontend-Specifications.md

File metadata and controls

107 lines (90 loc) · 6.05 KB
Raw

title: Wikibase Frontend Specifications subtitle: for the Library of Open Source Hardware (LOSH) command: pandoc Wikibase-Frontend-Specifications.md -o Wikibase-Frontend-Specifications.pdf --toc --pdf-engine=xelatex -V documentclass=report ...

Intro

On LOSH you can

  1. search OSH & filter results (LOSH's main purpose is to facilitate design reuse),
  2. access templates & guides to get your OSH project listed (which is easier than it sounds),
  3. access data directly (via Wikibase or RDF),
  4. suggest new features (via issues on GitHub),
  5. buttons

Target Group

In descending order of priority:

  1. OSH developer (e.g. maker) or anyone else looking for either specific OSH solutions or inspiration one's own project;
  2. Researcher or anyone else who wants to get an overview of the OSH ecosystem;
  3. Companies or other producing entities looking for OSH to manufacture and sell.

Functions

The main goal is to provide a frontend for the Wikibase instance in such a way that allows an average maker (hence someone not skilled or familiar in the use of Wikibase or RDF) to intuitively access & explore LOSH's data and use all other subsequently described functions of the LOSH. It also should have an appealing design, so people don't get shocked off by a design that reminds them on PHP forums from the '90s. We'll continiue using and promoting this platform long after OPEN!NEXT has ended.

Functions in the frontend include but are not limited to:

  • a prominent searchbar for free text search (presumingly searching the metadata fields function and name)
  • in the search, applying combinable filters, based on the metadata specification of LOSH, e.g. for:
    • license (and license categories),
    • documentation language,
    • file formats (and file format categories),
    • patent class (and representative labels for the same)
      • equals a 'function category'
    • TsDC-ID (and representative labels for the same)
      • equals a 'production category'
    • OTRL (and representative labels for the same)
      • …to filter for specific readiness levels of the design &/ the documentation
  • (link to) input of free-form SPARQL queries to query
    • Wikibase
  • 'threading' of versions/variants of the same OSH
  • compare search results by selected data fields
  • detail pages for OSH projects (displayed e.g. after clicking on a search result) containing e.g.:
    • metadata completeness (=extent to which the specification has been complied; also indicating the completeness of documentation)
    • data source
    • name
    • version + timestamp
    • repo URL
    • image
    • licensor, owner, organisation
    • license
    • functional description
    • number of contributors
    • list & number of self-designed parts
    • URLs to source & export files (including BoM and manuals)
    • production metadata (yet to be processed from here)
  • data export (download), of e.g.:
    • all design files known from the metadata
    • search results in various formats (e.g. CSV, JSON)
  • references to further information and tools

These functions form a preliminary scope for the frontend. As in every research project, this scope and lots of corresponding details are to be iteratively refined.
Hence, direct contact and regular technical meetings with engineers/developers would be ideal.

Development of the frontend will be carried out as a free/open source software (FOSS) project and therefor shall respect and comply with best practices from the FOSS community, specifically:

  • source code will be published under GPLv3 on a git-based online platform such as GitLab or GitHub alongside with
  • corresponding documentation, which follows community best practices and enables reuse of the source code, which itself
  • respects this principle and prefers reusing existing FOSS modules over hardcoded elements where feasible.

Examples

  • https://certification.oshwa.org/list.html
    • pretty basic interface allowing for free text search (name and functional description) and filtering for categories and licenses
    • list view allows fast comparism of the results by the displayed data columns
    • source code published here
  • https://search.openknowhow.org/
    • pretty basic interface, it's limited to the use of the search bar
    • gallery view of search results allows easy & fast pre-assessment of the results
    • source code published here
    • the database relies on metadata following the OKH specification, hence small YAML files in git repositories → so that comes pretty close to our scenario even though they neither use a crawler nor Linked Open Data
  • https://en.oho.wiki/wiki/Home
    • more advanced interface, already bringing in some features like filtering or discussions (see the peer-review-based 'certification' they offer)
    • gallery view of search results allows easy & fast pre-assessment of the results
    • mediawiki-based platform
    • source code published here
    • SQL database in the backend and lots of hardcoded elements (such as the category system)