Open Know How (OKH) ontology
Used for indexing, searching and comparing Open Source Hardware projects
Regarding the use of `schema:domainIncludes` and `schema:rangeIncludes` in this ontology: Looking at the definitions for the RDFS version of the two, `rdfs:domain` and `rdfs:range`: * https://www.w3.org/TR/rdf-schema/#ch_domain * https://www.w3.org/TR/rdf-schema/#ch_range and as described in this StackOverflow answer: <https://stackoverflow.com/a/74782257/586229>, multiple objects for the two RDFS properties mean, that *all of them* apply, simultaneously, not *one of them*. You may think of this as an `AND` coupling. We want the *one of them* meaning though (`OR`). The `schema:*` properties give us just that.
Martin Häuer <martin.haeuer@ose-germany.de>
Robin Vobruba (Open Source Ecology Germany e.V.) <hoijui.quaero@gmail.com>
Component
Either a module (MOSH) or Part (POSH); more component types may be added in the future
Module
Module of Open Source Hardware (MOSH)
Part
Piece of Open Source Hardware (POSH)
Software
Software (including firmware) needed to run & use the OSH
_scientific_ (that is: peer reviewed) publication that _contains_ the design files
Technical Standard
official standard used in the _design_ (not e.g. DIN SPEC 3105-1)
A file that forms part of the project, specified/located either by a URL (okh:url) or a repo-/project-relative path (okh:relativePath).
auxiliary file (neither source nor export)
outer dimensions
…of a module or a part
mass
others shall be able to identify/procure this component only by the given reference(s), MOSH → URL to corresponding release POSH → URL to containing folder STD → standard designation (preferably naming the _latest_ standard) BUY → unambiguous reference
version of OKH specification the metadata is following (different version → different data fields)
platform, where the crawler found the metadata (e.g. GitHub, Wikifactory)
platform where the OSH documentation is located (e.g. GitLab, Wikifactory or any self-hosted website or wiki)
e.g. auto (fully integrated platforms) or manifest file (for connected platforms)
URL to the place where development happens (typically the repository)" ; following this link people shall be able to contribute to the development (reporting issues, suggesting changes, connecting to the team etc.)"
Repoistory snapshot (=specific version) URL
version of this Component, preferably in the semantic versioning scheme (semver.org)
connects specific versions of Modules with their versionless superclass
IETF language tag following the BCP 47 standard e.g. en-GB denotes the language of the documentation for the component subject
organization/individual behind the hardware design (holder of intellectual property)
organization representing (most) contributors of this project
view complete list under https://spdx.org/licenses/
URL to legal code of a license without SPDX identifier, hence OSHWA-compliance is to be checked manually
permanent URL to evidence of compliance (OSHWA, FSF, DIN SPEC 3105)
design files of this OSH modules have been peer reviewed in a scientific publication
International Patent Classification (IPC)
Document identifier for the technical standard
functional description, e.g. what it actually does, what problem it solves, for whom, under which conditions etc. so if you wish that someone finds & uses your okh specifically e.g. for COVID-19-crisis response, include relevant keywords in this field optional: description of input, output and interfaces
links to the corresponding Contribution Guide
links to the corresponding Bill of Materials
Links to sub-components of the Module. In the case of that sub-component being an external Module, it has to refer to a snapshot of the RDF object representing that OKH Module. Each sub-component should also appear in the BoM.
Metadata addressing functionality, such as dimensions, material, weight, RPM,… (not standardized)
production-relevant metadata, such as material, manufacturing technology, outer dimensions, smallest tolerance, finest surface roughness
outer dimensions using OpenSCAD primitives
smallest tolerance class (following ISO 286)
DOI
this publication has a digital object identifier (DOI)
Project-/Repo-relative file path, directly starting with the first path element, *NOT* with '/' or './'
file URL
Global file locator, using either the HTTP or the HTTPS protocol.
Permanent file URL - It was not 'permanent', but rather 'frozen in time', and it was alsoThis was used in the karwler, but badly. Things simply should not be done that way, but rather with a separate manifest file, where either everything is frozen, or nothing is, and the manifest file (internally) itsself being marked accordingly.
following ISO 8601; see: <https://www.w3.org/TR/xmlschema11-2/#dateTimeStamp>
URL to a (generated) exported source file
Applicable Technology-specific Documentation Criteria, according to DIN SPEC 3105-1, e.g. `tsdc:3DP`