TOSH, MOSH, POSH relations

[moedn]

TOSH: top level OSH (MOSH_generic) MOSH: module (specific version of a TOSH) POSH: part (specific part of a MOSH)

render this class diagram (mermaid) yourself or click here

 classDiagram
      MOSH_generic <|-- MOSH_v_1_0_0 :subClassOf
      MOSH_v_1_0_0 --|> POSH_v_1_0_0 : hasComponent
      POSH_v_1_0_0 --|> POSH_generic :subClassOf
      POSH_v_1_0_0 --|> POSH_v_1_0_0_source :source
      POSH_v_1_0_0 --|> POSH_v_1_0_0_export :export
      POSH_v_1_0_0 <|-- BoMEntry_ClampRing_v_1_0_0 :refersToComponent
      MOSH_generic : repoURL
      POSH_generic : repoURL
      class MOSH_v_1_0_0{
          okhv
          version 
          …
      }
      class POSH_v_1_0_0{
          source
          export
          …
      }
      class POSH_v_1_0_0_source{
          fileURL(URL to specific commit)
          …
      }
      class POSH_v_1_0_0_export{
          fileURL(URL to specific version/commit)
          …
      }
      class BoMEntry_ClampRing_v_1_0_0{
          quantity
          …
      }

[moedn]

since files point to a specific commit and people will potentially not update the version field of POSH files, we decided to remove the version property in POSHes; their name equals the version of the MOSH

[cyroxx]

Is this some kind of bill of materials (BOM, https://en.m.wikipedia.org/wiki/Bill_of_materials) that you are modeling here? BTW, the link to the diagram is not working.

Another quick thought: I feel that all this LOSH, MOSH, POSH, TOSH might cause a lot of confusion, because they all sound very much the same, especially over a bad audio connection 😉

[moedn]

Hi @cyroxx :)

1. yes we want to track relations between parts; BoM = Bill of Materials, while sBoM refers to a specific, simplified template for a BoM.
2. Link to the diagram should work, hmm. Just tested it in a private window. But you can also just copy & paste the quoted code into any hedgedoc instance to visualise it. Or do it via pandoc :)
3. :D sí, understand your point about the wording. In fact it feels very intuitive when working with it, but of course, for newcomers that's just another term to learn. The ontology itself is not using these terms and I may also remove them from the documentation completely. Right now for working they save us a lot of time and confusion (that's why we implemented them) :)

[moedn]

Update

We'd like to remove the version field from MOSH manifest files and get the info from the git-tag instead.

Background:

• version info in manifest files would be almost always outdated otherwise
• tag points to a specific commit and gives us a clear reference for the whole repo
• people should use git-tags anyway

[moedn]

Update

We stay with a version field in the manifest files to keep dependency on API on the necessary minimum

[moedn]

relations resolved in new concept, see OPEN-NEXT/OKH-LOSH_copy#73 for details