Anyway, an idea.
Rather than put the "logical or" in the article, do it through tagging.
To make a Shovel
Make a blade of (acceptable shovel blade material)
Make a handle of (acceptable handle material)
Connect them with (acceptable shovel to blade connector)
Sheet aluminum 3mm thick
[acceptable shovel blade material: True]
Sheet plastic 6mm thick
[acceptable shovel blade material: True]
Aluminum piping 15mm diameter
[acceptable handle material: True]
Wood dowel 20mm diameter
[acceptable handle material: True]
Sheet Metal Screw
[acceptable shovel to blade connector: True]
[acceptable shovel to blade connector: True]
OK, maybe it will break down on more complex things -- where epoxy can't
bind with one of the materials. Then the instructions need to get more specific.
Anyway, for simple situations I think tagging could be used this way,
Also, there could be alternative list pages which list multiple items and
indicate via a page tag it is such an "or" list not a (by default) "and"
list. So, with "or" pages and "and" pages and maybe "not" pages, we could
build logical structures using Wiki pages that represent multi-factored
assembly possibilities of a certain level of complexity (not sure how to
specify thing like if you picked that over there, then you can't use this
I also think it possible to put in more complex statements with nested
"and"s and "or"s and "not"s and maybe "if"s as Mike suggests -- using some
sort of coding language is a block of text delimited somehow, and evaluated
in a safe way. It gets complex with things like "at least two from this
list". But maybe the system just needs to focus on simpler recipes and have
cut and paste for similar but not identical recipes. In the end, the recipes
are probably more for analysis, simulation, and mission planning. In the
field, people may look at several related recipes and mix and match. My wife
does that sometimes when cooking, adapting to what is on hand. :-)
As I mentioned it a reply to Bryan, given Wikipedia's explanation of basic
science, I am thinking that what is more important here rather than
explaining the science is the focus on the "factoring" of artifacts and
procedures. That is, breaking them down the way you might do top down
programming (and maybe some bottom up too, and meet in the middle.) And them
maybe linking to the science or to related design discussions.
Example of factoring:
Push button switch
Bakelite (and also a common Plastic Forming machine)
Plastic Forming machine
Push button switch (see above)
Anyway, then one can branch out.
Also. one needs to distinguish in a sense specifications from requirements.
A recipe is usually a specification. But using tags make part of it be more
like requirements -- what as required is anything with the tag.
Required: Something to conduct electricity
Required: Something to make and break a circuiet
Anyway, it seems like design may often float between these two levels. And
the more I look at the problem, the more I see a sort of computer program. :-)
When all you've got is a programmer, every solution looks like a program. :-)
OK, so I broke my timer rule to catch up. :-(
That looks like a simple metadata file to me, why not suggest a broad
overall specification for this set of file and we'll go ahead and push
the first yaml datatype for skdb?
> OK, maybe it will break down on more complex things -- where epoxy can't
> bind with one of the materials. Then the instructions need to get more specific.
The whole idea is to have both human readable and machine readable
instructions, so the specification for the object itself, the way that
you build the semantic datafile, could involve equivalent information
on how to make the machines make it [and if you don't have those
machines, then plaintext output to human readable text would be a
possible layer enhancement].
> Anyway, for simple situations I think tagging could be used this way,
> perhaps. :-)
The yaml-datastruct idea solves that ... why not use it?
> As I mentioned it a reply to Bryan, given Wikipedia's explanation of basic
> science, I am thinking that what is more important here rather than
> explaining the science is the focus on the "factoring" of artifacts and
> procedures. That is, breaking them down the way you might do top down
> programming (and maybe some bottom up too, and meet in the middle.) And them
> maybe linking to the science or to related design discussions.
Yes, refactoring in as much as the parts get split up into the
manageable chunks via git repos.
I think you're still ignoring me. Just saying.
Yep, the test was alright. I know what I know, and know what I don't
know -- like the derivation of the taylor polynomial approximations of
trigonometric functions, or how that connect back to the
limit-of-a-sum definition of e, natural logarthims, and integrals in
general. That alone could have helped significantly, but I just
haven't been able to track down that sort of information on the net
(no "math symbol search engine").
>> The yaml-datastruct idea solves that ... why not use it?
> I agree (assuming yaml is somewhat like xml). Metadata is really more
FWIW, I share Paul's concerns over XML. So, YAML is sort of like XML
in that it's a markup language, but I think that might be where the
similarities cease. So if you needed a comparison, Paul's been
mentioning RDF, and YAML is more like RDF than XML. I'll need to go
back and read up on the technical differences, but *in practice* re:
what I have done before, which wasn't computationally or technically
intense, XML docspec runners in perl haven't been that bad, but again
- I wasn't trying to do much, so might have missed something under the
hood over the years. Is anybody else impressed by the yaml.org website
presentation of their work? Somebody put some good thought into that.
Not something seen everywhere.
> appropriate than the tagging system and is way more extensible. My
> main problem is, as ever, the front end, and how all this stuff can be
> glued together. I'm confident I can learn anything ending with "ml" in
Frontend is ikiwiki, *plus* opportunities to do git pulling of the
content so that you can edit in your own type of frontend, whether
vim, vi, pico, nano, notepad, or even by running magnets over your
hard disk to flip bits on the plate (too extreme?).
> a day or two, but how would it be implemented? Is the plan to do
To what extent are you asking about the implementation? The interface
(above)? Or the use of these metadata files? The use of it involves
autospec, to validate the files with respect to the units that they
provide, as well as making sure the user has all of the software
necessary to unserialize the data objects, and the from there - things
get kind of sketchy - but basically I'm pulling that together with
Eric, some guys over at piclist, and so on. I suspect that the 'matter
compiler' will have to be bruteforced too, i.e. can't rely on magical
reconfigurable (physical-fabricational) ISAs. One clue might be in
whether or not you can feed the gcc team a Verilog/VHDL file to the
generators and come up with a platform-specific compiler. I doubt it,
but it's worth investigating first, since it'd provide a lot of good
direction to work off of since it's all about the compiler analogy.
> something entirely different than what we've done so far, or
> incorporate it into the wiki? Is there any way a non-PC person could
> make changes to a metadata file without using something like
> subversion? A good solution might be employing an editor right on the
Yes, they would just click edit on the wiki. The wiki is a frontend.
> wiki (the only example I can think of is the AIML/XML editor on the
> site pandorabots, and to get to the editor you have to sign in and
pandorabots ... sounds familiar. Back in 2002 I used to hang out on
wiredbots, but that community died sometime in 2004. Do they live on?
> To mirror what Doram said in another thread, we can look up yaml, we
> can look up apt-get, but we aren't smart enough to figure out how they
> would work together in the front end (use little words please, and
> keep in mind that the world is never going back to command line, as
> much as we hate it :-)
Hrm. Little words. Well. You make a data structure. That's basically
what the metadata file is - a structure, a class. And then other files
in the (dot skdb) package could also be yaml too. So to make a
datastructure, you write up some python. Ex:
> Heres our average user: a bio major that gets on the computer and
> comes across openvirgle and decides to add in a page on the effect of
> Cr on the nervous system. They will give up as soon as A) more than
They'd use http://sbml.org/ ;-)
> one download is required B) It takes more than 30 seconds to figure
> out the GUI. If we want to develop an awesome back end first that
> takes a comp sci master to use, thats fine, (I don't mind being left
> out of the development loop, I can write new articles) we just need to
> know that a GUI eventually can and will be done, and how the backend
> is glued together.
I guess you can use a GUI to make a picture of different classes. But
the UML craze didn't last long because, as Ben says, "apparently
drawing pretty diagrams isn't going to lead to writing good (hell,
Because that is is some sense half the work? :-)
I remember when I was collecting Hydra from near-shore pond plants in Swan
Pond with Prof. Larry Slobodkin
and I shook the plants to rid them of the water dripping from them (a habit
with wet things many people have :-) and he said, "You're shaking off the
very thing we are trying to collect!" (Hydra are small creatures that live
in water and attach to plants and other structures.)
Ah, I miss those days rowing around with him on Swan Pond and just chatting
and "simply messing about in boats": :-)
I still don't know if anyone has seriously studied what I noticed it his
lab: that such simple animals seem to deploy their tentacles in very
effective patterns given their surroundings and the related liquid current
flows. Maybe a great PhD topic for someone these days that emergent behavior
is more accepted as a topic of research.
>> OK, maybe it will break down on more complex things -- where epoxy can't
>> bind with one of the materials. Then the instructions need to get more specific.
> The whole idea is to have both human readable and machine readable
> instructions, so the specification for the object itself, the way that
> you build the semantic datafile, could involve equivalent information
> on how to make the machines make it [and if you don't have those
> machines, then plaintext output to human readable text would be a
> possible layer enhancement].
Buy low, sell high? :-)
>> Anyway, for simple situations I think tagging could be used this way,
>> perhaps. :-)
> The yaml-datastruct idea solves that ... why not use it?
>> As I mentioned it a reply to Bryan, given Wikipedia's explanation of basic
>> science, I am thinking that what is more important here rather than
>> explaining the science is the focus on the "factoring" of artifacts and
>> procedures. That is, breaking them down the way you might do top down
>> programming (and maybe some bottom up too, and meet in the middle.) And them
>> maybe linking to the science or to related design discussions.
> Yes, refactoring in as much as the parts get split up into the
> manageable chunks via git repos.
> I think you're still ignoring me. Just saying.
No, I'm saying many of your comments are at an insufficient level of detail
to be tremendously useful in coding up a specification or adding and tagging
content as I see things. But your comments are still appreciated as a step
towards engagement with the details. And maybe I am missing something. I do
think your thoughts on leveraging Git and/or ikiwiki to make a distributed
system are innovative, but as I'm focusing on a centralized system right now
in order to make progress on the stuff you seem to be shaking off :-) those
comments are not that helpful to me specifically. But in the long run, sure,
I think a distributed system will be better. :-) And frankly, in twenty
years, there *will* be a free distributed OSCOMAK and SKDB system whether we
work on it or not. As I say here:
"And to the people on the MacArthur Foundation committee, who turned this
idea down as a proposal (as Stella) for a graduate fellowship about twenty
years ago, well, as per the bit on struggles above, thanks too. The
struggles probably made me a much better person. :-) Too bad that all our
collective failings potentially delayed implementing Robert Muller's 1980s
idea for an an ordering of our knowledge. At least now we have Wikipedia.
And someday, no dobt, OSCOMAK will merge into a Semantic version of that.
And probably be the better for that. As will the ideas of Memex, Xanadu,
Augment, Smalltalk, and so on (including all the unnamed human aspirations
for such systems all the way back to the first standing bear cave painting
used for instructing the young of the ancestors of the Haudenosaunee), as
all these efforts become part of a free Semantic noosphere."
See, the person who will really succeed at all this is probably someone
like, say, Saul Griffith:
"Saul Griffith has multiple degrees in materials science and mechanical
engineering and completed his PhD in Programmable Assembly and Self
Replicating machines at MIT. He is the co-founder of numerous companies
including: Low Cost Eyeglasses, Squid Labs, Potenco, Instructables.com,
HowToons and Makani Power."
He has the money, connections, degrees, etc. Someday he will turn his mind
in a more focused way to OSCOMAK and SKDB like issues and realize the
fundamental ethical limits of capitalism and go free and open soure. I'll
quote him here as this is good advice to you echoing mine previously:
FSB: How do feel about the "genius" label?
SG: I hate it. I don't believe in the concept of genius. I think there are a
lot of really smart people in the world, and a few of them work really hard.
I'd be a lot more comfortable if they called it the "manic idealist
FSB: Why did you choose the entrepreneurial path rather than just go to work
for a think tank?
SG: Think tanks seem to do exactly too much of that. Thinking. While I love
thinking, I like doing more. At Squid Labs we toyed for a while with
describing ourselves as a "Do-Tank." The entrepreneurial path seemed to be a
good way to move forward with a different set of constraints to working for
large companies or within Academia. It is by its nature fast moving and
impact and action-oriented.
FSB: What advice do you have for other entrepreneurs?
SG: Learn to live cheaply. Learn to live like an animal. One thing we had
going for us is we all spent a lot of time in grad school, and long periods
of grad school teach you how to live well on a low budget. That's good
training for becoming entrepreneurs. It's easier to have a high-risk
tolerance when you know where the dumpsters with free food are. Also, I
definitely think you need to focus on a specific project in the market that
you're going after.
Which reminds me, a year or so ago I was musing on using our PlantStudio
evolutionary arts software to intelligently design origami animals in a
quasi-evolutionary way (he likes origami). But now that I think on it, there
is no reason OSCOMAK could not be used to document origami folds. It's an
interesting problem; I too have long been interested in origami.
This is a current New Yorker article on this issue; read it while it is hot
as the New Yorker hides things after a week:
"In the Air: Who says big ideas are rare?"
Incidentally, that article details the evil way most innovation is done
these days as "for-profit" and "academic" research. :-(
To begin with, the article documents diverting public funds earmarked to
useful tasks to poor people in the world, like, say, studying water
purification using nanotech
to, say, quantum cosmology: "Wood bent the rules for Myhrvold; the Hertz was
supposed to be for research in real-world problems." Which is about what you
might expect from someone more interested in big bangs: "Lowell Wood was the
technical director of Star Wars" :-( Still, people can grow spiritually and
ethically and creatively, look at, say Ted Taylor,
or even, to an extent, me. :-)
Anyway, that article, and how "Intellectual Ventures, Inc." works is an echo
of the mistake Google made with the "Inc." part of "Virgle". Chain a bunch
of scientists and engineers (financially) to desks, surrounded by lawyers,
and say innovate or else. :-( And innovate about ideas me and my similarly
financially obese. friends thought important. No surprise such people likely
"Studies Find Reward Often No Motivator: Creativity and intrinsic interest
diminish if task is done for gain"
or alternatively just take that as justification to starve other people.
Anyway, I'm lucky I already got my "genius" award. I married her! She being
the genius of course -- in a lot of ways,
but especially in being able to support her child and deadbeat husband
working only half-time herself, and doing so mostly while making the world a
better place, and at the same time helping make me a better person, in part
by putting interesting books in front of me she is reading herself. Anyway,
I told her if I ever got one of those MacArthur grant thingies, I'd have to
turn it down if it did not include her and me as a team. :-) She said that
was stupid, I should take the money, and she just wants to know that
someday, historians may look back on this time and say, "Things started to
get better for the world around then, but we don't know why." Well, at least
*I* know why: :-)
Fortunately, our main number is unlisted so I'll never have to worry about a
"Mission Impossible" phone call. :-)
Anyway, as you can see from the thanks page, Stella/OSCOMAK is no longer
"mission impossible" and I'm just as happy to know well funded people like
Saul Griffith are now (almost) on the job so I can spend more time with
family, friends, and nature (and maybe even looking at health insurance
Still, I know George Miller told me, wistfully being only human, that the
reason he got so much research done in his life is that he never won the
Nobel Prize. :-) Seriously, those kind of things weigh you down, at the very
least with giving speeches to graduating High School seniors. :-)
He didn't do too bad for himself in the end:
Not so bad for the man who planted words. :-)
But I think my wife's sentiment is better. But few have her nobility of soul
I think sometimes.
"The superlative horse"
For balance, and mostly about me, when I met her she combined just about
ever petty difficulty I had rejected (unfairly) just about every other
potential wife in my life. :-) From poverty to crooked teeth and a bad back.
See, people can learn to be less shallow. :-) I'm a lucky guy I married her. :-)
Paul, yesterday I replied to Mike's email that was at the sibling level
to the email that I am replying to. I know that you sent this email
(that I am replying to) long after my reply to Mike's, but I am
wondering if you read it, and if so whether or not the issues still
hold. And, of course, I don't mean to implying that this last sentence
by you indicated to me to write these questions, I'm just wondering.
I'll hack out some more words to ground all of the components together
in a better reply if so, but on the other hand -- if not, that last
(rather large paragraphed) email I sent, plus the one I mention above,
might do the trick. Don't know, though.
Can you refine this example a bit?
In SKDB metadata file, what would be an example of a ClassName?
Or an example of a <statement-1>?
(Doing any better with my questions, Doram? :-)
This is nothing new. :( How do they say it? There is nothing new under
> Can you refine this example a bit?
> In SKDB metadata file, what would be an example of a ClassName?
There are multiple types of metadata files that are needed. First,
there's the metadata file that would be downloaded as an equivalent to
debian DSC files which describe the dot deb file, what's it in it and
how you can use it. But the basis of the metadata file is simply yaml
in the first place, and it's expected that this semantic-style yaml
would be used for other standardized file formats even within the dot
skdb files (equivalent to dot debs in the analogy). So an example of a
classname in the case of a metadata file (of the type that DSC is in
debian) would, first and most importantly, simply include the !!
statement per the yaml documentation (this says "this is of type
blah" -- type blah is predistributed with agx-get and represents a
rooting node on which all of this is based). Now, one of the classes
that I suspect would be developed for metadata representation will be a
list of contributing authors. Hm. Maybe another example would be a list
of internal files within the dot skdb file -- like the contents of the
zip files up on my site:
That one happens to be a collection of anti-aging/biogerontology
research from Aubrey de Grey that I read through in a day last year
before attending a public chat session with him over the net. Fun
stuff. Anyway, you'd dump this content there, or somewhere [and tell
them how to get it], and then translate it into the formal models,
semantics, etc., plus the python code for manufacturing via JVM as Paul
recommended [but this is a part that has yet to be fleshed out
entirely, there are a few options to choose from. It's also not
immediately needed for our collective infohoarding sessions].
> Or an example of a <statement-1>?
Oh, variables like where on the internet the main project can be found,
pgp keys to confirm that it's in fact the right hash sum and so on.
> Bryan Bishop wrote:
> > Hrm. Little words. Well. You make a data structure. That's
> > basically what the metadata file is - a structure, a class. And
> > then other files in the (dot skdb) package could also be yaml too.
> > So to make a datastructure, you write up some python. Ex:
> > class ClassName:
> > <statement-1>
> > .
> > .
> > .
> > <statement-N>
> > http://docs.python.org/tut/node11.html
How much typing work can it be to include one specific name for a class and
include on line of code? But the actual *thinking* involved in presenting
those two may be enormous, as well as the level of commitment and bravery in
risking laying out something in detail that would almost certainly be buggy
and incomplete (as almost all real programs are :-) instead of focusing on
picking implementation technologies (as important and difficult as that is
too, but still much easier).
Anyway, despite all that I think we are still making progress here as
relates to SKDB.
Here is an "Artists's Conception of Cassini Saturn Orbit Insertion":
Here is a picture of the real thing:
See all the specific detailed words in the real thing? :-) Examples:
* UVIS Telescope
* Thermal Control Louvers
* Hydrazine Rocket Thruster Clusters
And that is just a surface level of detail. There are multiple detailed
levels of understanding behind each component as well as the way they
interact to support a mission. As well as the ways the parts and the whole
are assembled, dissembled, recycled (maybe someday, though it would more
likely end up in a space museum :-), and diagnosed and repaired (even if
Those are the kind of examples it might be useful to think about with SKDB.
You could even use Cassini as a starting point for your interstellar space
probes. :-) Try putting it into your SKDB system as a test case.
And that Cassini mission btw was IMHO a waste of US$3.26 billion
compared to say, these sorts of missions:
"NASA Studies Manned Asteroid Mission"
"NASA Planning Mission To 40-Meter-Wide Asteroid"
(even though NASA could instead just pick a large asteroid and put a habitat
seed factory on it for about the same money, which would be even better
IMHO, but they still cannot admit an interest in space habitation other
than, at most, a Mars flags and footprints program)
Or of course, instead maybe NASA could have funded OSCOMAK ten years ago
or their own followup to AASM:
"Advanced Automation for Space Missions"
which might have given us that seed factory capacity by now. :-(
Still, if thinking about the specifics of Cassini as an example can help you
build SKDB, then maybe that US$3.26 billion was in the end well spent. :-)
I would not be so tough on this point except your continual promotion of
SKDB in some senses undermines OSCOMAK, which is OK with me nonetheless (you
ultimately will succeed is eclipsing it with SKDB no doubt, if for no other
reason that youthful zeal :-), except I'd prefer that OSCOMAK (which is
currently operational, even if buggy and limited and badly designed IMHO :-)
be undermined by something substantial and a going concern, :-)
and not IMHO by SKDB "conceptual art" :-( however beautiful and thought
provoking it is.:-)
"By focusing on the future rather than the present, Microsoft can
continually position its competitors' products against ones it may choose to
sell in the future. Few products in the tech world can hope to compete
against what may be offered in just a few years. This devastating business
strategy works so well that we have given it a name: vaporware."
Now, granted, we are designing in public so I don't want to shut down
brainstorming by calling it "vaporware". I'm just pointing out that risk,
especially since you don't talk about SKDB in future terms (but more as if
it were operational right now). Tomorrow, or next month, or next year, SKDB
might well be the next Wikipedia. But it won't be IMHO unless you start more
directly engaging examples of real content or with realistic use case (e.g.
Cassini) in your own creative design process. So, I'm not just being
critical, I'm also trying to be helpful too for your eventual success with
SKDB once you engage with real content.
In any case, I am still trying to convey here the difference between (to use
a carpetry analogy Doram might like :-) talking about brands of saws and
building a house (or even just designing one on paper). :-)
And NASA might rightfully say the same thing about my comparing Cassini and
OSCOMAK. :-) So people can be wrong. And I'd acknowledge this spacecraft I
inhabit may well have "a fault in the spacecraft's communications antenna".
:-) On, the other hand, maybe that is just the result also of NASA's HAL
9000 bureaucracy being on the job and conflicted within itself:
Not quite. I'll do an example later today, but I checked the archives:
That might hold you over until I am done with Iron Man.
And a chat with the local transhumanists :-)