search

iop-alliance / OpenKnowHow

A metadata specification to enable the collection of distributed, standardised metadata of open source hardware designs
GNU General Public License v3.0
1 stars 0 forks source link

OSH Ontology #6

Open hoijui opened 11 months ago

hoijui commented 11 months ago

Let's develop an Ontology for OSH designs, manufacturing and maybe more (e.g. recycling).

To define the scope more specifically/to limit it more, we can discuss in here.

Current suggestion:

Scope of the Ontology

To allow different actors in the OSH universe to interact using similar wording. Such actors includes:

_From here on, the content was copied over from OPEN-NEXT/OKH-LOSHcopy#11, as this ontology would form the base for solving that issue.

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.

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 commented 11 months ago

_(Also copied over from issue OPEN-NEXT/OKH-LOSHcopy#11, author: @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. ;-)

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?

hoijui commented 11 months ago

_(Also copied over from issue OPEN-NEXT/OKH-LOSHcopy#11, author: @moedn)

Moin! Some unasked comments from my side:

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 commented 11 months ago

_(Also copied over from issue OPEN-NEXT/OKH-LOSHcopy#11, author: @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?
    1. I am trying to express different concepts:
  3. design leading to a modular machine: the design will lead to a modular machine.
  4. 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.
  5. modular machine: The end user can exchange modules (e.g. OSE US tractor motor modules)
    1. Because the more we rely on base concepts, the more different ontologies become compatible with each other, leading to more inter-linkage & compatibility
    2. :-)
    3. I don't know... can we call them hardware? where would they go in the osh-dir-std?
    4. 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.
    5. 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.