Main coordination doc

Important parameters

Title: Open Knowledge Standards

Objectives	Outcomes
Apply the OKH standards to your open source hardware project / venture. See also PDF.	You streamline your documentation procedures and align yourself with emerging standards
Provide feedback to IoPA to further improve these standards.	IoPA integrates feedback from your practice into the OKH standards design process.
Connect the OKH standards initiative with other endeavors within the open source hardware and material peer production ecosystem.	All participants build general awareness and forge/strengthen many-to-many collaborations.
Activities will be harvested and deposited primarily into the OVN wiki. All participants can collaborate on content destined for social media.

Problem solution statement

Open Know-How is all about sharing knowledge on how to make things. With dozens of open hardware organizations and over 80 content-hosting platforms and thousands of designers sharing open hardware designs, there is little consistency as to how know-how is documented or shared. Makers struggle to locate what they need, not knowing which platform to find it, what the intended use is and therefore struggle to adapt designs. Whilst the knowledge is ‘open’, it is not freely flowing in the spirit that open-ness suggests.

The objective of this specification is to improve the open-ness of know-how for making hardware by improving the discoverability, portability and translatability of knowledge.

Session Breakdown

Lynn’s discussion about alignment between Valueflows and IoPA.
Lucas’ discussion about Holo / Holochain and true commons.
Max’s demo of OKH and Solid: LOSH Library of Open Source Hardware

OKH - Valueflows (Sensorica, FabCity)

Discussion led by Lynn, representing the interests of ValueFlows.

Opening statement:

Work towards unifying or re-using the efforts underway that want to use OKH and Valueflows (VF). There are possibilities to take steps towards more integrations between the OSH design processes and the making / manufacturing of those designs.

Here is a sketch of the current and currently planned situation.

Solid arrows mean it is planned or in-process. Dotted arrows mean it has been discussed, and may be planned.

To support more integration between the design phase and the making phase, it would be good to map OKH and VF recipes, and document possible integration points. Some high level observations:

The main difference is that VF ties together the processing (routing) and the BOM (bill of materials), instead of documenting those separately for the end item (module/thing/resource). This also applies to the maker documentation in FabCity, which itself is more aligned with the VF pattern because it is broken up into pages. On the other hand, since OKH has a separate document for each component (sub-thing), that might accomplish a lot of the VF breakdown. What is not accomplished is the break-out of parts and tools by process or assembly step within the instructions for one thing/module.

Another potential issue is the lack of standard formatting of the BOM file, and potentially other files.

Also, is it possible to tie the OKH Part/Sub-thing to its own set of OKH data as a Module/Thing?

The following diagram is to help with discussion during the workshop on VF and OKH data structures.

Lynn says that FabCity uses software that supports Valueflows, using Valueflows API - See their Interfacer project. Moreover, FabCity has taken FreeCAD (a special version) and inserted metadata that can lead to IKEA-style documentation capabilities (markdown files). They have implemented “step”, which is a “process” in ValueFlows (doing something), which can lead to assembly / production instructions. This is what Valueflows calls Recipes (planned work) out of the 3D CAD file. A Recipe in ValueFlows follows an input–process–output pattern. The output can be input to another process.

Antonio, and Robin: Parametric design in FreeCAD is constrained to manufacturing operations - computed-aided manufacturing CAD (computer-aid design) + CAM (computer-aid manufacturing). This can be used to spit out operations, workflows through metadata.

OpenScad is parametric, but it is not constrained to manufacturing operations.

Blender is not parametric, not like mesh modeling.

Distinction: OKH driven by the supply side (supply chain - how to provide a thing). ValueFlows is mostly demand-driven (how to create a new thing, production, innovation).

Confirmation from Bob:

Valueflows is mostly demand-driven. The original pattern was dependent demand which was workshopped at the 1997 Pattern Languages of Programming conference. A dependent demand is one coming in from outside the frame of reference, and the pattern is how to satisfy the demand, which is where recipes came in. It is mostly [about production] not about innovating designs, altho it is not opposed to innovation..

So how can we merge both? Seams like Recipes are the link. Also, we note that the BOM (bill of materials) is a shared artifact in both Valueflows and OKH, but not treated the same way. The OKH Manifest links to a BOM, which lives within the file structure of the thing. There is no specification on the BOM in OKH. There are some ways that people use to express BOM. IoPA has the choice to adopt some of these ways, specifications, so that the machine knows what to expect. BOM tends to be industry specific. Also, there are different practices between mechanical and electronics practices / community-based. The ValueFlows vocabulary can influence the process.

Bob wants to be part of this conversation.

Where does the Process live in OKH? In OHK, the assembly of a product uses modules. Might include many steps, and the BOM is going to include all the parts that go into that assembly.

Sarah talks about feedback received by IoPA from partners: missing assembly instructions, processing of material parts, practical workflow – ValueFlows Recipe can be the link. Also, there is no field in the OKH Manifest for that practical workflow.

Max stated that the assembly instructions are sensitive to domain (electronics, mechanical) and are culture-sensitive. It may not be practical to aim for a universal script. BOM and the assembly instructions (or Recipe) could be on the same file. The ontology may need to be changed. Max also talks about LOSH, about discoverability.

Related to LOSH, what is the crawler? The OHK specifications were published with the intent of making projects more discoverable, indexing methods. The crawler uses APIs and scans collaborative platforms (such as Gitlab, Github, Thingiverse and Wikifactory) for projects, downloads them and converts them to RDF (metadata about the project) and lists of things. So the crowler LOSH + OKH form a search engine.

Robin – there are different ways to get OKH Manifests. The goal is to programmatically produce an OKH Manifest from the data about things extracted from various platforms. The OKH manifest can be manually created, or it can be created using the crawler parametrically (more limited); another option that could potentially be explored/previously discussed is the possibility of a browser extension to generate a manifest.

Tibi asked if the crowler can also decompose these things into constituent parts and present these parts as things, leading to composability (remix), adjacent possible, increasing innovation speed (the crux of commons-based peer production). Apparently this is not yet possible.

Assembly instructions, processing of material parts, practical workflow - manufacturing Recipes could be a way to map this. https://github.com/valueflows/valueflows

Lynn on composability - asked if a part can be treated as a thing?

Tibi - Perhaps we need pattern language, heavily used in software development, as a higher level specification of designs. This can provide meaning to parts, within a thing, as in the role / function they play. This can lead to the creation of categories of parts.

Sarah introduces the topic of the quality of content / data, which is not yet supported by OKH (this is also related to documentation).

Regarding portability: OKH manifests can indicate which files should be bundled for porter/Solid App. Are there use cases for establishing BOM alternative parts list that they were not intended for; this is not part of the OKH standards per se, more in alignment with definition of workflow. Quality control/assurance of produced items is another area to explore (see GOSQUAS conversation on that point). UX testing of bundled files for reproducibility of an item indicates that assembly instructions, finishing (or produced parts - filing prints, checking for fit, etc) is a need.

Do we adopt linkdata as a way of expression OKH?

There is a lot of data in OHK that is not in ValueFlows, which is good.

OKH has info about licensing, using a standard. Projects can be divided into parts only when people find these parts.

A digital resource must also carry with it information about how it was produced (agents, roles, hours, $, etc.)

IoPA uses a very simple metaphor: distributed manufacturing, an NGO paying a number of local fabrication facilities to produce something for local users. This metaphor considers digital artifacts as representing finished “products”. We need to consider the entire lifecycle of open source hardware, how the first version is created, how it is improved, forked and remixed.

From the event, harvest something for communications on what Holochain can do uniquely, for the open hardware ecosystem.

True common - stand alone digital artifact

Discussion led by Lucas from Holo.

This is more about how descriptions about things and about the process to make them are stored and shared in a network. We would consider more aspects of storage, permanency, sharing, search and retrieve, and collaboration. This connects with the hREA demo proposal.

Holochain is Unenclosable carrier. What does it mean in terms of uncapturable commons?

Holochain is about composability and federation in terms of applications (hApps).

In the previous discussion we understood that platforms, as intermediaries, create a problem of interoperability that IoPA is trying to solve. Could Holchain solve that problem at the source?

Tibi - This is similar to recycling, having sorting of materials done at the source, taking away the need to centrally process waste material. In a similar fashion, what Lost + OKH are trying to do, it to scrape all these collaborative platforms of their “things” and try to sort them out and standardize their presentation. The standardization could be done at the user end, by the user, using the proper tools, and categorization would come easily after.

Valueflows + hREA → new specification of digital asserts (resources), unenclosable commons (what we can call true commons).

Lucas - Desire to enlarge the ecosystem, interface Holochain, Scuttlebot, IPFS, …

Forking of a digital resource is an important feature, inherited from open source practices. Forking a digital resource should always generate a link from the new resource to the original and vice versa. Thus, one can always go back to the ancestors of digital resources.

The remix case must also be taken into consideration.

Holochain turns the economics of open source hardware on its head - what’s important becomes what you can share, not what you can have. Emphasis on sharing, composability, federation.

Hardware: cost of reproduction is not zero, as opposed to digital artifacts. Thus, hardware is a very different medium to play with, larger complexity as compared to software. Forking hardware leads to tolerance issues, requiring new testing and integration-related work.

Tibi - this is an advantage, since it creates a natural economic dependency among peers (having the author involved is more desirable then just having the model), which leads to creation of communities / network/type organizations, extending collaboration. This leads to OVN / Sensorica’s argument of economic interdependence between innovators.

In essence, the distinction between a knowledge economy and a know how economy. The digital artifacts must be designed in a way that can facilitate aggregation of know how.

Economic reasons put constraints on documentation standards, because focusing on the supply side may not be sustainable, since that only leads to capitalism parasitizing commons-based peer production. The economic constraints to make commons-based peer production sustainable comes from the demand side, how the stuff is made. The standards must take care of both perspectives, perhaps leaning more on the demand side.

Pattern language: what are the patterns of innovation within CBPP with traditional institutions? What patterns do we know about? For profit, foundation, academia, … Identify the flows, patterns, within the ecosystem and look at the ontology / taxonomy, focus on prioritization, not just which part goes with which, beyond feature interaction. What is the metadata or these standards, info that we gather, in terms of people focus, know how, perhaps we also need to include the know why? Perhaps even know when? That leads to interfaces between systems. Is there a pattern where we carve out some resources from the other system to use in the new system? Hybrid, metamorphosis.

Motivated by a sense of urgency (unifying force), construct a unique value proposition into the ecosystem.

Simple implementation of current standard

Discussion led by Max, representing interests of IoPA.

Max is proposing to use OKH Solid app to implement the OKH standards. He will coordinate this during the workparty.

Solid is a specification that lets people store their data securely in decentralized data stores called Pods, which are like secure personal web servers for data. When data is stored in someone's Pod, they control which people and applications can access it.

More info about the OKH Solid App

Another area where efforts could be applied is on bringing ontology into alignment for operability of the OKH-LOSH crawler. Robin Vobruba has been working as a part of OSE Germany to bring this into alignment and could advise on current status/what’s needed.

Pathway for manifest > porter > local or Solid storage

https://solid-app.internetofproduction.org

OKH Solid App setup notes

Navigate to provided link, create a pod on any of the provided community server options
“Add Project” via URL or locally stored manifest (.ttl)
“View project details” will show a listing of design files as bundled/pushed to your pod
Max will also show Penny to inspect your pods, and share with others; every app uses a different container (OKH pod is unique)

We opened https://LOSH.opennext.eu/ which is a search engine, crawler.

Used to find a different use case of the manifest.

Decided that linked data is the way to go.

LOSH is the largest library of manifests, using rdf.

Lead to OKH-LOSH version.

Start with the manifest file, use the manifest file to recreate the project’s file structure in a different environment. P2p project portability.

Tooling that allows sharing of the manifests and being able to recreate the data.

OKH project portal. Allows us to port all the data files into our machine.

What is Solid? Open protocol, in development for a very long time. It is a storage protocol, store the data in PODs. Protocol for file storage and identification and access controls too. Anyone can store PODs. There is a community server service, we can also run our own Solid server. Organizations are running their own implementation. Once you get an instance of a POD. W3C standard. Mostly created for storing personal data.

Once you have a Pod, you can create projects. [adding details further up in the doc where the Solid links are, T!b!, regarding setup notes, organize as you see fit] - SH

A project may provide a list of parts, in various formats, for 3D models, some are PDF, etc.

Decouples the content from the original storage medium.

If I get a copy, in the future may add the capability to log me as a copier and the original author. Also can log what’s changed by me, from the original file.

RE: decoupling - an upgrade/future dev recommendation from UX testing - global download for all associated/bundled files (grab them all in one go).

Manifests could be modified to include provenance - when you share with someone else, when using linked data, you can trace back to genesis and what’s changed/by whom between iterations.

The work we’re looking to do - alignment of ontologies to allow for feasible generation/discovery of manifests, to increase test cases/use cases.

For Solid to work, the links to the bundled files need to be public.

Use https://gitlab.opensourceecology.de/verein/projekte/LOSH-rdf/-/tree/main/RDF

This is a repository of files generated by the crawler.

From there you can use

Choose a project,

Take the link and use the https://solid-app.internetofproduction.org (create a pod)

From there, you can import a project. You need to navigate these files and find the project.ttl , open this file, copy the URL and paste it into the

file click create new project and paste the link to open it

In essence, all we need is to get access to the project.ttl file, its URL.

In the future we can store that .ttl file in our own Github repo, no need to rely on the crawler.

Once you get the .ttl file somewhere, you open https://solid-app.internetofproduction.org/ (create a Pod), press create new project and paste the address to the .ttl file in there. The project will be transferred from its own repo to the pod.

The .ttl file has the metadata including the content already.

https://penny.vincenttunru.com/ allows to edit a project already in a POD.

You can replace linked design files in your manifest and group them with the project within your pod.

Generate the manifest file

Write turtle, RDF syntax.

To manually generate a manifest there is a tool online that presents a form that generates a toml file. Press download, name it as OKH.toml place it in the root of the Github repo.

The crowler goes on platforms, uses API and generates the toml file.

Solid: provide people to share data without a specific platform. None of the platforms were involved specifically.

Open the source

{Signalization tools}

{symbol for process/status updates - use this to signal important milestones in the process}

{symbol for notes - use this to post reminders or short messages for self or to collaborators}

{symbol for important information - use this to attract collaborators’ attention}

{symbol for ToDos - use this to signal to your collaborators about what they can do}

{symbol for alternatives: enumerates possible solutions to consider}

{symbol for reasoning: presents arguments about possible choices}

{symbol for Information: tells you how stuff works.}

{symbol for growing consensus: a summary of a section of this report}

Find icons from the noun venture

https://thenounventure.com/