Modularity issues

[hoijui]

As it is now, in RDF, a Module can have "sub-modules" by means of the okh:usesModule property:

okh:usesModule
  a owl:ObjectProperty ;
  rdfs:label "uses Module" ;
  rdfs:comment "refers to a *release*/snapshot of an (external) OSH Module used in this design (should also appear in the BoM)" ;
  schema:rangeIncludes
    okh:Module,
    okh:WebsiteUrl ;
  schema:domainIncludes okh:Module ;

There is no way this could come into existence through the krawler though, as it is at the moment, because it always first generates a TOML manifest (maybe just by downloading it), and then creates RDF from that. Our TOML specification does not allow for sub-modules though, as of now - only for Parts as sub things of a module.

In the course of investigating this, I read up on some of our docu, read the specification(s), and found that (at least to me), it is quite unclear what a module and what a part is. I also found no explanation why we have this distinction, nor a list of the differences, nor a guide when to use which.

This is how it is now (up until August 2023 and at least 945af83), to my best knowledge, and after reading through this repo a bit:

• A Module is usually in its own repo, but could be in a sub-folder in its own repo too
• A Part is in a sub(..)-directory of .a repo, and specified in the manifest of its parent-module
• A Module can have sub-parts
• A Module can have/use other(/sub-) Modules -
  but so far only in RDF, not in:
  • the TOML-manifest
  • the Web-UI for creating a TOML-manifest
• A Part can not be in its own repo and have its own manifest file
• A Part can not have sub-Parts
• A Part can not have sub-Modules
• Parts can not have a BoM (specify installation requirements #136)
• A Module is a thing that could likely be useful for other assemblies/modules, independent of any parent-modules
• Parts - and here it gets very cloudy to me, or say, this is my own interpretation -
  can be physically separate from the module, but would not make sense to be used in an other module?

Honestly, I am totally confused, and don't know what to tell people who are asking about this stuff.

[moedn]

jupp, totally agree! in fact, we had it, but it apparently got lost over time

suggestion:

• a module is an assembly with a dedicated function (hence it must be defined)
• a module can consist of parts and other modules; parts are in the same repo, other modules in other repos
• sub-modules can be referenced in two ways:
  • IRI to LOSH RDF object (e.g. https://www.thingiverse.com/thing28455/1.0.0#Project. Then it doesn't matter on which platform the module is hosted (e.g. Wikifactory projects don't have a manifest file))
  • version-specific/snapshot URL to the repo, if the module is not yet part of LOSH
    • this could be a good hint for the crawler to check out those modules too
  • I believe both ways could be merged, since LOSH uses repo URLs to reference modules. however, I think in practice it could get messy when users don't use the right links (or we add a community-based method to fix that afterwards)

in a TOML file it could look like this

[…]

[[module]]
reference: https://gitlab.com/OSEGermany/ohloom/-/tree/ohloom-0.10.0

comment:

Parts can not have a BoM (currently)

↑ since "A Part can not have sub-Parts" there's also no BoM (just a comment on the "(currently)"

[hoijui]

Wow... thanks a lot @moedn, that helps a lot! :-)

IRI to LOSH RDF object

"sub-modules can be referenced in two ways:

1. IRI to LOSH RDF object"

I think this makes sense in general, but not yet, because the tech we are hosting is still WikiBase based. as Soon as we have it changed to RDF and under a stable domain/URL, it will totally make sense!

Parts BoM

Ahh.... so a part is really just a single part? e.g. it can be the lid of a case, made up of a single piece of plastic that is 3D-Printed, but it could not be a lid of a case that is made up of two metal-parts that are screwed together?
so the parts are basically the items in the assembly guide then?

Rest

.. perfect! :-)
will try to get the [[module]] part into the TOML spec then!

And once we are finished in this issue (the above two things are clear to me), I will adjust the docu and tech-spec. around Parts and Modules.

[moedn]

IRI to LOSH RDF object

yea, I gave it another round in my brain and I guess, just referencing the version-specific repo would be the best option. as outlined, this also allows the reconnection inside the LOSH database.

Parts BoM

jepp, Parts are standalone parts. In the TOML file, you'd not reference all items of the BoM, but only the self-designed one that users will find in the repo. all the others need to be acquired anyways, and don't allow for modification etc..

Rest

comment on [[module]]: of course we could also just add a property and list all associated sub-modules there, but I like the similarity with [[part]], so it's essentially the same process as adding a part, just with different properties

---

cool, thousand thanks man! 🔥

[hoijui]

one more thing regarding this topic: in RDF, we have these two properties:

okh:hasComponent
  a owl:ObjectProperty ;
  rdfs:label "has Component" ;
  rdfs:comment "links to parts of the module" ;
  schema:rangeIncludes okh:Part ;
  schema:domainIncludes okh:Module ;
  .

okh:usesModule
  a owl:ObjectProperty ;
  rdfs:label "uses Module" ;
  rdfs:comment "refers to a *release*/snapshot of an (external) OSH Module used in this design (should also appear in the BoM)" ;
  schema:rangeIncludes
    okh:Module,
    okh:WebsiteUrl ;
  schema:domainIncludes okh:Module ;

okh:Component is the super-class of both okh:Module and okh:Part, but okh:hasComponent only works for okh:Parts, not for okh:Module. So I would say we either make okh:hasComponent work for Modules too, and remove okh:usesModule, or we rename okh:hasComponent.

An other question I have is, why is it hasCompnent, but usesModule?

[hoijui]

How to call non-Part & non-Module things

Example: screws
Screws are standard items which will appear in the BoM but not in the manifest, because they are neither a module nor what we call a part in OKH. Do we have a name for them already? BoM-items?
We may not need this in the ontology, but we still need it to differentiate and explain in the associated text, and maybe even in comments in the ontology. (need might be too strong of a word, but it would be helpful for sure)
To me, it would make more sense to call both of these (what we currently call parts, and things like screws) Parts (as a super-category), and call screws Standard-Parts and a 3D-printed part a ... maybe manufactured-Part?

Then again, I know though has already flown into this, which I am not aware of.

[moedn]

my suggestions:

1. ontology

• hasComponent for parts and modules
• remove usesModule

why is it hasCompnent, but usesModule?

→ no reason, that's an inconsistency

2. non-parts & -modules in manifest files

The BoM lists all components that I need for the module – the ones I need to buy and the ones I need to build myself. the manifest file helps connecting the files that I need for things I need to build myself (CERN OHL uses a very similar distinction; we could also use their system (#available-components)). so we do not list all parts of the module in the manifest file, but only the ones that are part of the repository (+ open source submodules)

hope that makes sense :)

[fosterlynn]

Hello! I work with @hoijui on the FabCity INTERFACER project, and work on the Valueflows ontology. @hoijui asked me to comment here, one question being the English names. I'm a native English speaker, and have lots of data modeling experience, but I am not a maker. And ValueFlows is expressed in RDF, so I have studied it a lot, but I have never actually developed with RDF, and feel I have some practical gaps. So we will see, and I won't be insulted in the least if you disregard my thoughts. :)

Names:

• Component - To me this implies not being a final "product" that can be used on its own. It is more like a "part".
  (Note the name "product" I don't like either, it implies something that will be sold more than something that will be used. I can help look for a better one if you want one.)

  Dictionary definition:

  A part of a mechanical or electrical system.

• Module - I am more familiar with this in software, where it is also more like a part, and implies it can be used as part of different software applications.

  Dictionary definition:

  A separable component, frequently one that is interchangeable with others, for assembly into units of differing size, complexity, or function.

• Part - Yes, a part.

  Dictionary definition:

  A portion or division of a whole that is separate or distinct; piece, fragment, fraction, or section.

One bigger thought on naming: OKH-LOSH doesn't actually represent any of the above, if you are coming in from the bigger picture. It represents designs for those things, not the already built things themselves. Or for the things you always just buy, like screws, it represents the exactly defined "type", not the actual thing. To me, it is important to situate your ontology in the rest of the world, and not make assumptions that people already know it is all about designs.

Another thought, about separating your Modules and Parts: It makes sense that makers now always use "commodity" parts like screws that can be ordered from AliBaba, or bought from the hardware store down the street who got them from AliBaba. But in the future, if we look towards more and more localization of production, those distinctions might disappear more and more. Maybe some day there is a small factory in your town that makes screws, and has its own BoM for inputs to those, and is part of your maker network instead of outside it. Maybe some day it goes all the way back to mining the ore. Or not, I don't know how you think about it.

Questions that affect naming:

1. I guess this is always about hardware? Do you ever include things like textiles? (I noticed in FabCity and in our own (sadly dead) local maker space, textile makers are part of it.)
2. On the Software (subclass of Component) that is used in the hardware, is it also the design? Or is the software actually already programmed and tested when you represent it in OKH-LOSH?

[moedn]

Hey @fosterlynn ! nice to finally e-meet you :) sorry for the super late reply

regarding your questions:

1. "hardware" is a very flexible term here. I wouldn't include textiles, but I know too little about it. the ontology was built with mechanical/electrical hardware in mind
2. yet OKH-LOSH only considers references to software releases. it's not seen as part of the design but as a "virtual component" with a specific version

regarding component: yes, a component is a part of something else, but can be anything, incl. liquids (which one wouldn't classify as a "part" I guess) or software. I just used this as a meta class

regarding module: in mechanical engineering, this would be called a "sub-assembly". we wanted a term that is abstract enough to be understood in many domains. a module is essentially an assembly of parts, fulfilling a defined function. it is also possible (and encouraged) to reference external modules (e.g. RepRap's extruder design when developing your own 3D printer)

regarding linking to other ontologies and the bigger context: I believe this gap came by the lack of experience we have in this field. definitely something worth fixing

regarding alibaba: OKH-LOSH doesn't make any assumptions about how or where the parts of the design are obtained. standard parts are described by an official standard (as most screws; and therefore fungible), purchased components exist somewhere in the market (and may raise practical limitations when replicating the machine, depending where on earth you're located) and self-designed components are included in a repository. neither the BoM nor the references in the metatdata will replace the final shopping list (but will help to create it)

--

thanks for your feedback! hope my answer makes sense and are least a little bit helpful. generally, I'm not very attached to any of these structures or names. I have little to no experience with ontologies and we just did our best to construct something that makes sense and works for us. so feel very free to adjust it to your liking :) in that case I'd like to be kept in the loop to check the results against my engineering perspective and give feedback.

[fosterlynn]

Hey @fosterlynn ! nice to finally e-meet you :)

Same! And thanks for your reply, yes it is helpful!

[hoijui]

I am brainstorming about this since a few days, and also asked Michele Langhammer and Mark Neugebauer from the FCHH network, whether they may know an ontology dealing with such stuff from industry (or elsewhere).

If not, I will start writing down some ideas and questions, and maybe work on a diagram.

My current mental model, consists of two parallel levels/spheres: virtual and physical. I think of it a bit like the main "levels"(?) in ValueFlows, there: Knowledge, Plan and Observation (so 3 levels in VF, 2 in our case):

These spheres are different, but for the most part - or at least roughly - an object in one sphere has an equivalent object in the other sphere.

• e.g. a screw ("available component") in the physical sphere has a specification in the virtual sphere
• a machine in the physical sphere has a design in the virtual sphere
• an (indivisible) part or sub-assembly of the machine, has a (reusable-)design in the virtual sphere

Some questions (mostly for myself and maybe discussions; numbered just to make them referenceable):

1. Standard vs. Specification? (probably the later should be used primarily, and the former only for official/somehow approved specs)
2. are physical&virtual good words (for the two levels)? or maybe rather touchable&untouchable? or touchable&conceptual? or ...
3. should we call these two "levels" or "spheres" or something else?
4. is hardware something that is actually "hard", only? (or should we rather call it just hardware?)
5. ... or rather "something you could potentially buy in a hardware store"?
6. could touchable be a good word to include hard things + textiles plus liquids?
7. ... what about gas ... is it touchable? (I would say yes)
8. do terms like experiential or tangible make sense for our ontology?
   (that might include hard, soft and liquid things, but not most gases)
9. Is that too philosophical already?
10. some (one-piece) parts that are machined in a single go, thus being one part in the manufacturing process, may be broken off/split into multiple parts for the assembly process. Is this an indivisible part? how do we practically handle this ... do we need an other level/sphere, separating the physical one into manufacturing and assembly?
11. ... would we need even more spheres, e.g. for recycling?
12. How do we clearly and intuitively differentiate between a modular design (e.g. one part of a machine can be used as-is for an other machine as well) from a modular machine/touchable (e.g. the OSE US tractor, which - after being fully built, has a modular motor compartment, where one can place an electric motor or a gasoline-fulled one)?
13. Should we setup the ontology in a way, where each individual is of class "Something"/Object (completely generic), and then specified through its properties: touchable, designed, specified, liquid, hard, likely-reusable, machined, standardized, a thing, whole, a piece, a part/component of something bigger, ...?
14. Could we reuse ontologies from physics/chemistry? (researched a bit in early 2023, did not find anything useful)
15. How do we deal with natural/grown parts (e.g. a branch from a tree)? -> high variances, not specified, not fungible, no technical drawings or other exact specifications, ...
16. Where do "wet" components fit in? (e.g. biological networks of neurons, mycelia)
17. How do we include/specify/deal with the requirements of parts? (e.g. the conditions required to keep biological networks of neurons alive and/or functional)
18. In english, there is a fixed expression: "Is this really a thing?" -> can/should we make sure this makes sense within our ontology, as it is commonly understood? .. or better not?
    19 How can/should we limit the scope of our ontology?

[hoijui]

In my mind, it would be nice if we could make this ontology such that it can be used (and potentially extend to) anything we come around in the OSH universe, not just what OKH needs right now in its current form. This way it can form a common basis for a lot of technology to come, but also for people to talk to each other about the subject.
... and who knows, maybe it can even help to replace the term Open Source Hardware with Open Source Touchable or the like. ;-)

[hoijui]

Maybe the goal could be, to limit the ontology such, that it fits into a legible diagram (including icons for things) on a single page?

[moedn]

Moin! Some unasked comments from my side:

• I believed we abandoned the original scope of the issue :) maybe we should continue the discussion in a new issue or elsewhere (possibly an online meeting)
• not quite sure what the industrial ontology is aiming to solve – is there a problem description somewhere?
  • I'm a big fan of modular solutions; tiny modules that work well for themselves, are easily understood (low complexity) and integrate well into a bigger scheme (that's essentially what standardization bodies aim to do with their documents :) )
  • hence I'd be in favor of clear scopes for standalone ontologies, that can be connected to a bigger scheme without conflicts
  • but that's also just an opinion from someone with little to no experience in that field :)

regarding your questions:

1. as I'm reading into this right now: that's a non-trivial question :) as (my personal) rule of thumb: more harmonized is better, BUT users of the standard/spec shall be in control of it, otherwise it's not representing their needs (industry controls "conventional" technical standards, IETF controls internet specifications etc.)
2. depends on what you're trying to express, but yes, for now I like the terms (you could also use (non-)tangible
3. depends on what you're trying to express, levels suggest a certain order
4. not necessarily "hard", but at least tangible :) (in the end, there seem to be various hardware definitions circulating)
5. nö
6. I believe the word you're looking for is "tangible artifact"
7. yes :)
8. depends on what you're trying to express
9. depends on what you're trying to express :D
10. not sure why we'd need the concept of a indivisible part (= átomos (Gr.)) here. parts are arbitrarily defined during the design process of hardware – and of course you can take defined parts from other machines and make other parts out of them (e.g. I liked to make parts out of standard components as those are very cheap to get in a reliable quality). and that's the difference between BoM and "shopping list": BoM includes only your parts (and quantities, specs etc.) and the shopping list states where you're getting the materials from. e.g. shopping list may include parts from another machine that are then processed into parts that appear in your BoM
11. depends on what you're trying to express :D (but possibly yes)
12. isn't a modular machine a physical representation of a modular design?
13. if you're trying to map the world – yea, why not? :) (but why?)
14. if(13=true → yes)
15. when we know why we want to deal with them, then we also know how :)
16. fit into what? e.g. in an earlier version of the TsDC I introduced the concept of "auxiliary components" e.g. machine oil
17. hmm… I'm not getting the purpose of this, sorry, no comment
18. not quite sure, seems like philosophical question with different answers :)
19. should we: I'd recommend so, yes. How can we: by setting a scope :) I believe it's best to start with a problem description

[hoijui]

ehhh wow, thank you @moedn!! :-)

10. 1. why we need the concept of an indivisible part (= átomos (Gr.)): I also don;t know, but to my understanding, this is what we currently have in OKH(-LOSH) as the meaning for "Part"
    2. so shopping list is before manufacturing, and BoM is between manufacturing and assembly?
11. I am trying to express different concepts:
    1. design leading to a modular machine: the design will lead to a modular machine.
    2. design made using modules: the design uses modules that are also used in other designs. the end-user of the machine might not think of the machine as modular, because he might not be able to exchange any modules.
    3. modular machine: The end user can exchange modules (e.g. OSE US tractor motor modules)
12. Because the more we rely on base concepts, the more different ontologies become compatible with each other, leading to more inter-linkage & compatibility
13. :-)
14. I don't know... can we call them hardware? where would they go in the osh-dir-std?
15. One goal we want to achieve some-when, is: if we have the design of a piece of hardware (or tangible) and it's meta-data, to figure out where we can build it. We might order the wet parts, and the machine they will end up in can guarantee the correct environment for them, but until the machine is build, the lab might need to supply it.
    ... ok I admit, this is a kind of edge-case, and might be easily avoided by just building the machine before ordering the wet parts or something like that.
16. ahh... ok... problem description ... I just got tired now, but I would say: create an ontology that allows hardware designers, builders, and people who build software, standards and ontologies related to OSH, to refer to a common vocabulary, to be more or less sure they mean the same things, and to commonly discuss about these concept, and develop them in the community, when used.