Interfacer demo 12/2022

These are questions and comments from Lynn on the recorded Interfacer demo from December. This is looking great, nice work everyone!

Project

How does Project translate to VF? Are you defining it as something new? Looks sort of like some combination of Organization (team), Resource Specification, Plan?

Complex assets

On this, does the software create the processes that produce the inputs, based on what was included? Or might they already be in the system from other people making the parts in the context of Interfacer? Seems like they might already be in the system. (Possibly part of my confusion on this is my question of what is a Project, which you are choosing for your inputs.)

Notes on the VF actions:

• Actions define the effects on resources.
• cite makes sense when the resource is not decremented or incremented, and remains available (like in this case a design).
• When you are actually assembling a part (resource) into a final product, like the bike mirror input, then it is a consume action. It will decrement inventory of the input resource. (You may not care about that level of operations?)
• If you do want this to be (or connect to) actual parts used, you will also need a quantity, like if the bike consumed 2 wheels. Even if you are not doing inventory, the agent that produced the wheels might need to record that you consumed 2 of them to evaluate their contribution later, or to just pay them for them?
• On services, you can use produce but it then forces you to create a mythical resource which doesn't make sense to inventory, but you need something to cite. If you use deliverService, you can just use that event as both output of the bike frame manufacturing process and input to the assembly of my fancy bike process. Same for the bike assembly service.
• (Note since you already know design vs product vs service, you could still automate choosing these actions without bothering the user.)

Relating to design metadata and maker doc

A lot of this level of detail would already be data in the design and maker documentation. So if you want that to eventually connect to the actual making, it would be good to pair them up in terms of data model and granularity. Often the maker doc will reflect many sequential and/or parallel assembly processes, like for the microscope or the laser cutter. Each process will know its particular inputs and outputs. And tools. And maybe skills and time to make.

So in the above example, the bike frame manufacturing might be a separate process, possibly even done in a different lab. The bike frame design would be an input to that process, not the bike assembly process.

But, as always, there is flexibility in the model for granularity of processes, my comment relates to the situation of having maker doc…

LOSH question

Very cool you are getting LOSH data! I understand these would be just designs?