"Thus where years ago the skill and ingenuity of the mechanic were
monotonously and patiently utilized in the hand production of a number
of parts of great accuracy to a certain attainable degree of
duplication they are now directed to the devising and constructing of
one part or tool or a set of tools which will produce other parts or
tools in endless repetition."
http://en.wikipedia.org/wiki/Interchangeable_parts
"""
Around 1778, Honoré Blanc began producing some of the first firearms
with interchangeable parts. Blanc demonstrated in front of a committee
of scientists that his muskets could be assembled from a pile of parts
selected at random. Other inventors who began to implement the
principle included Henry Maudslay, John Hall, and Simeon North.
In the U.S., Eli Whitney saw the potential benefit of developing
"interchangeable parts" for the firearms of the United States
military, and thus, around 1798, he built ten guns, all containing the
same exact parts and mechanisms, and disassembled them before the
United States Congress. He placed the parts in a large mixed pile and,
with help, reassembled all of the weapons right in front of Congress,
much like Blanc had done some years before.
The Congress was immensely impressed and ordered a standard for all
United States equipment. With interchangeable parts, the problems that
had plagued the era of unique weapons and equipment passed, and if one
mechanism in a weapon failed, a new piece could be ordered and the
weapon would not have to be discarded. The hitch was that the guns
Whitney showed congress were made by hand at great cost by extremely
skilled workmen. Whitney, however, was never able to design a
manufacturing process capable of producing guns with interchangeable
parts. Historians Merritt Roe Smith and Robert B. Gordon have
demonstrated conclusively that Whitney never achieved interchangeable
parts manufacturing.
"""
Assembling parts into working guns in front of congress is quite
theatrical. (Also, if anyone can get me Blanc's 1790 memoire, I'd
appreciate it.)
An interesting reference to read on this subject:
* Woodbury, Robert S. (1960). "The Legend of Eli Whitney and
Interchangeable Parts." Technology & Culture 1.
Woodbury mentions that Eli Whitney was really struggling for money,
and generally argues that Whitney was scamming congress at the time
because he didn't really have "interchangeable parts". And in reality
interchangeable parts was really just a way of saying replacement
parts, not broader compatibility issues, which I'll get to in a moment
below. It's certainly in dispute whether or not Eli Whitney was a hero
of the industrial revolution (per Woodbury), and the question I'm
wondering now is if the industrial revolution ever really delivered on
the original promises that seemed to have just kind of popped up out
of the culture at the time (rather than any informed discussion on
standards and possible routes to explore).
http://en.wikipedia.org/wiki/Lego
"""
The company's flagship product, "Lego", consists of colorful
interlocking plastic bricks and an accompanying array of gears,
minifigures and various other parts. Lego bricks can be assembled and
connected in many ways, to construct such objects as vehicles,
buildings and even working robots. Anything constructed can then be
taken apart again, and the pieces used to make other objects. The toys
were originally designed in the 1940s in Europe and have achieved an
international appeal, with an extensive subculture that supports Lego
movies, games, competitions, and four Lego-themed amusement parks.
Lego pieces of all varieties are a part of a universal system. Despite
variation in the design and purpose of individual pieces over the
years, each remains compatible in some way with existing pieces. Lego
bricks from 1963 still interlock with those made in 2008, and Lego
sets for young children are compatible with those made for teenagers.
Bricks, beams, axles, mini figures, and all other parts in the Lego
system are manufactured to an exacting degree of precision. When
snapped together, pieces must have just the right amount of strength
and flexibility mixed together. They must stay together until pulled
apart. They cannot be too easy to pull apart, or the resulting
constructions would be unstable; they also cannot be too difficult to
pull apart, since the disassembly of one creation in order to build
another is part of the Lego appeal. In order for pieces to have just
the right "clutch power", Lego elements are manufactured within a
tolerance of 2 µm.
"""
Wikipedia has good information on lego CAD and the manufacture of lego parts:
http://en.wikipedia.org/wiki/Legos#Design
http://en.wikipedia.org/wiki/Legos#Manufacture
Some properties of legos:
* precise repetitive manufacturing of the same artifacts
* a "universal system" [within their company at least :-)]
* each piece remains compatible in some way with (all) existing pieces
With legos, not only can you replace red block with red block, but you
can replace red block with green block slightly extended. There is
more than one type of part that is compatible with each other part,
and each part can be remixed into other constructions the designer
comes up with. In manufacturing and design engineering, there is an
opportunity to design to pre-existing standardized parts, esp. see
screws and other little parts. And it's my understanding that this
(albeit primitive) form of standardization was brought about by parts
catalogs and part identifier numbers/names. You can generally only
replace parts in machines with exact duplicates, whereas with legos
there's a set of available parts that are options for solving the same
'problem' (lego designs don't really face all of the issues of
mechanical design, so the problem is usually aesthetic). Apparently
the definition of 'interchangeable parts' in manufacturing is more
related to the precise repetitive manufacture of artifacts for
essentially standard replacement parts constrained to measurements and
tolerances. It's easy to see how I could feel betrayed by
"interchangeable parts". It's a fairly good encapsulation of an
important concept. Legos have some sort of intricate link to my
childhood (I still play with legos), so the natural feel of having
both exact duplicate replacement parts but also a sort of
quasi-*functional* interchangeability/compatibility must have
transferred when considering the concept of "interchangeable parts".
Maybe that's how many others think of interchangeable parts too, it
wouldn't be a longshot-- legos are but one of the many concepts that
'interchangeable parts' could be associated with.
With the example of standardized naming of parts and components, I'm
pretty sure that I'm wrong and that there are many manufacturable
artifacts that are interchangeable with other parts for solving
basically the same functions, but my guess is that these are in
isolated instances throughout product catalogs. In electronics, the
golden standard for standards and compatibility, there are many
replacement parts from different manufacturers, and thousands of
different types of LEDs, or 555 timer chips that can be dropped into a
breadboard without sweating it - even the individual pin pathways are
standardized. The other day I was excited to find ECIX, "Electronic
Component Information Exchange":
http://archives.si2.org/si2_publications/
EC PinPak XML example:
http://archives.si2.org/si2_publications/pinpak/SampleInstances/KM736.xml
http://archives.si2.org/si2_publications/pinpak/Parts/Samsung_KM736V687A/KM736V687A.pdf
((wonder if I should go hack out some code and submit to gEDA for ECIX
file support.))
Basically that's an XML representation of the Samsung KM736 datasheet
(PDF above). Thomasnet.com and Globalspec.com both have 'datasheets'
for some of the products on their site, but it's hit-and-miss since
some products within the same category don't have all of the
information filled out and so on. Amazon is terrible at doing
datasheets, but NewEgg at least has a wizard-like sidebar that guides
users through picking specific stats and numbers for the items to
search for, so I'm guessing NewEgg put the squeeze on manufacturers or
is manually entering data with hired kids.
Anyway, there's far from an available "datasheet spec for standard
artifact engineering," except for electronics. The reason I bring this
up is because of some of the code I commited to the repositories the
other day, and for the interface between packages/artifacts I was just
using a Measurement object plus a string for material identification,
encapsulated in an ingredient class, which is far from a good idea.
It's hardly sufficient for its task, and so will be thrown out with
the trash once the better ideas spontaneously turn into code. In part,
the code commited was also demonstrating "interchangeable steps", or
rather interchangeable solutions to abstract steps asembled in the
form of a recipe.
Realizing that the original concept of interchangeable parts wasn't
taken to the next level of, say, compatibility, shows a possible
avenue of discussion for talking about new ways to do design and
manufacturing.
> Realizing that the original concept of interchangeable parts wasn't
> taken to the next level of, say, compatibility
For-Profit corporations often purposefully avoid or even break
interchangability/compatibility. Think about cell-phone chargers and
batteries.
Why do they do this?
How can we (as Open Manufacturers) avoid traveling these same
scarcity-based paths?
Each 1st-World consumer discards tons of plastic each year that could
be recycled and pressed as we please if only we had the land, machines
and fuel...
But wait.
*Somebody* owns such things already.
Just not the 'us'.
The 'we' hasn't quite figured out how to co-own the physical sources
used to supply it's own needs.
Those who already own such things would require far too high a price
to rent the facilities - and would more likely deny you flatly.
So how can a group of humans co-own the material Means of Production
they need for their own survival without working against each other as
Capitalism pits us?
I think you are talking about capturing at the most general, flexible
level the inputs and outputs of processes (so that you can then figure
out what processes can connect to what other processes).
You've got this concept of an "ingredient", a thing which can come out
of a process as an output, and can go into a process as an input. It
feels ungrounded in that it's just a name. And you've looked at the
idea of grounding it by describing it entirely by descriptive
"measurements".
Theoretically you could do that; if you could attach enough metadata
to ingredients, and enough metadata based rules to inputs and outputs,
you should be able to describe enough about the "ingredient" to be
able to decide whether it is usable as an input to process X or output
of process Y.
I think in practise though that the metadata will necessarily contain
a subset which describes what the ingredient "is", rather than
qualities it "has".
eg: an example Bryan and I have talked about before:
Say I'm folding origami shapes. I can break this into two main steps:
1 - Acquire paper
2 - Fold paper into shape
For Acquire Paper, I might have these alternatives:
- PaperMakingMachine: Input: Pulp, Process: Choose type of paper,
press Go, Output: Paper
- BuyPaper: Input: $X, Process: Press Go, software acquires paper and
has it delivered, Output: Paper
and for Fold paper into shape I might have these alternatives:
- OrigamiMachine1: Input: BrandX Letter Paper, Pattern in Language A,
Process: Press Go, Output: Folded shape
- OrigamiMachine2: Input: A4 Paper or compatible and Pattern in
Language B, Process: Press Go, Output: Folder shape
So there's this problem (amongst many) of how you decide whether
outputs of some of those processes can plug into inputs of other
processes.
What I was saying above: You can describe a particular kind of paper
"SpecificPaperX" by adding all kinds of metadata, like "width=21cm",
"height=29.7cm", "Thickness=0.5mm", "creaseholdingability=0.7",
"basematerial=pinewood", etc etc, but eventually you are going to have
to include "paper", "standardA4paper", etc; metadata that tells you
what it is, not just facts about it.
So then different processes (regarding different equipment or
whatever), created by different people in isolation from one another,
are going to clash here. Either they'll use different metadata
attributes (the BuyPaper process talks about "Paper" while
OrigamiMachine2 talks about "A4Paper") or they'll use the same
attributes to mean different things (eg: does the PaperMakingMachine's
output "Paper" mean exactly the same thing as the "BuyPaper"
processes' paper?)
You can solve the second problem using namespaces.
PaperMakingMachine.Paper vs BuyPaper.Paper are now different
The problem of compatibility requires standards, which you implement
using inheritance type dependencies
We might create a definition of paper standards called
"OMStandards.PaperStandardsA". In that, is defined "Paper",
"LetterPaper", "A4Paper", plus maybe more complex types of rules?
Then we get PaperMakingMachine and BuyPaper and OrigamiMachine1 and
OrigamiMachine2 and find a way to change the inputs into something in
terms of OMStandards.PaperStandardsA.
You might hassle manufacturers of OrigamiMachine2 to update their
definition of OrigamiMachine.A4Paper with the information ("is-a:
OMStandards.PaperStandardsA.OfficePaper.A4Paper")
You might change your BuyPaper code to only choose from papers that
you know match the OMStandards definition, so that you can know that
the output of BuyPaper is OMStandards compliant.
You might not be able to modify your PaperMakingMachine to be
compliant (can only work in terms of PaperMakingMachine.Paper) but
might create another machine to cut the paper to OMStandards compliant
sizes:
CutPaper: Input: PaperMakingMachine.Paper, OMStandard choice, Process:
Press Go, Output: OMStandard.Paper (specific descendant as chosen)
which you can then combine with PaperMakingMachine to make something compliant.
etc.
So note that the standards effort is the same as ever. People define
standards in an accessible format, then people doing more specific
work can refer to the standards data to define their own processes. Or
they can derive sub-standards from those, and so on transitively.
By breaking the implicit assumption of capitalism; that you can
acquire leverage with accumulations of capital.
This is already happening in the information space. In areas we care
about, lack of money is less and less a barrier to publishing and
being taken seriously; and conversely, wads of cash wont get you
credit in intellectual communities.
In the space of physical stuff, the clear imperative is to invent new
processes that people can use in their garage using professional
hobbiest budgets.
The more we can get done at that scale, the less important big capital is.
Capitalism isn't going to wither on its own, any more than the
bureacracy was ever going to in Marx's vision (sorry Marx). You have
to wither it with extreme predjudice.
You sentence doesn't parse. What?
oh, sorry, I get what you are asking
http://en.wikipedia.org/wiki/Terminate_with_extreme_prejudice
So there's this problem (amongst many) of how you decide whether
outputs of some of those processes can plug into inputs of other
processes.
What I was saying above: You can describe a particular kind of paper
"SpecificPaperX" by adding all kinds of metadata, like "width=21cm",
"height=29.7cm", "Thickness=0.5mm", "creaseholdingability=0.7",
"basematerial=pinewood", etc etc, but eventually you are going to have
to include "paper", "standardA4paper", etc; metadata that tells you
what it is, not just facts about it.
So then different processes (regarding different equipment or
whatever), created by different people in isolation from one another,
are going to clash here. Either they'll use different metadata
attributes (the BuyPaper process talks about "Paper" while
OrigamiMachine2 talks about "A4Paper") or they'll use the same
attributes to mean different things (eg: does the PaperMakingMachine's
output "Paper" mean exactly the same thing as the "BuyPaper"
processes' paper?)
So note that the standards effort is the same as ever. People define
standards in an accessible format, then people doing more specific
work can refer to the standards data to define their own processes. Or
they can derive sub-standards from those, and so on transitively.
ok
This is exactly what I was saying when talking about using the paper
cutting machine, CutPaper, after PaperMakingMachine to transform the
output.
> This information, however, in my opinion doesn't need to be standardized.
> The framing model is so flexible that I don't see any reason why you
> couldn't produce this framing information dynamically.
this is actually what I was talking about.
> Once you have the
> information that frames X and Y belong to the same kind of representation,
> and that Y and Z belong to the same kind of representation, then you can
> immediately infer that X and Z also belong to the same representation.
Absolutely.
You do have some standards here, ie: a shared set of meaning between
separate pieces. X and Y must refer to some pre-existing "frame" (what
I called a standard) and Y and Z also belong to some pre-existing
frame.
This is a damned hard game to play on a large scale though; when there
are a lot of different frames in the same space, you end up
introducing a lot of adapters to get you from one frame to another.
Theoretically ok, but super messy, and sometimes in practice there are
limits to this.
So the existence of standards in the more usual sense; actively trying
to pull everyone doing the same thing into the same frame.
But still voluntary. If there is OMStandards definitions of paper, and
someone wants to make a machine that works with EvilPaper and someone
else makes another machine that can turn EvilPaper into OMStandards
paper, yay, that works.
> So
> what you'd have, ultimately, are a series of "de facto" standards which can
> always be bypassed the moment someone sees the need to do so.
yes
> The first problem you allude to: "the BuyPaper process talks about 'Paper'
> while
> OrigamiMachine2 talks about 'A4Paper')"; just means you're going to be stuck
> if you stay with a two-level, data/metadata model. In semiotics there's
> this notion called unlimited semiosis which means, lets say you have a
> representation (sign) and it's object, which together compose it's
> interpretant. That interpretant, in turn, is simply a representation for a
> further object. In the above example, A4Paper is merely a representation of
> Paper, taking "Paper" to be the more general, unspecified category.
Inheritance
>
>>
>> So note that the standards effort is the same as ever. People define
>> standards in an accessible format, then people doing more specific
>> work can refer to the standards data to define their own processes. Or
>> they can derive sub-standards from those, and so on transitively.
>
> I really think that if you use a flexible semiotic model you're not going to
> need to standardize as such because you've dealt with the problem of
> incommensurability head-on with the above-mentioned framing-model for
> representations.
Yes, this is an important point, but you will still need actual
standards to reduce the friction of working together, eventually. We
could all speak different languages on this list, and if between the
list members we had the will and skills to translate each post into
each needed language, it'd work, in a sense. But everyone talking in
English has a certain efficiency compared to that proposition, even if
you do lose subtleties here and there.
> Anyway, thanks for hearing me out,
> Kevin
No dramas, they are good points.
Where I talked about Namespaces, they are the Frames you are talking about.