[Hplusroadmap] Fwd: Re: Halo Semantic MediaWiki video & a plan to embrace it?

[Bryan Bishop]

----------  Forwarded Message  ----------

Subject: Re: Halo Semantic MediaWiki video & a plan to embrace it?
Date: Wednesday 23 April 2008
From: Bryan Bishop <kanzure at gmail.com>
To: openvirgle at googlegroups.com

On Wednesday 23 April 2008, Paul D. Fernhout wrote:
> For example, there are lots of Trekers who could put in schematics
> for versions of hypotheticas Shuttlecraft with warp engined, and
> there is bound to be a bit of overlap with a real SpacePod like, say,
> the design of polymers for the carpeting in both. We would need
> someway of tagging fact from fantasy, of course -- or at least
> specifying what assumed laws of physics went with the device or
> material (the processor architecture in Debian terms -- Einstienian,
> Tolkenien, StarTrekian, Babylonian, Lost-in-Spaceian?) are necessary
> for different devices to work (at least in a simulation. :-) The Well
> World series by Jack L. Chalker is a touchstone here. :-) Anyway I
> have a perhaps misguided hope that if we could tap into even 0.1% of
> effort that goes into sci-fi fandom, and get them hooked on putting
> stuff in, some of them might start getting interested in technology
> that we know can work.

The tagging issues are simple to resolve - first, even if something is 
*not* tagged fiction, the fact that there is no functional, confirmed 
implementation would be enough. Confirmation can be through a network 
of trust via pgp keys, which I was thinking of using anyway with the 
meta-repo idea, so it's all good. I don't see why you are insisting on 
these mediawiki implementations that *lack* the repository control that 
would come in handy with oscomak+skdb. I am pretty sure this is due to 
my lack of explanation of what I've been considering, but if not then I 
would genuinely appreciate your analysis of the defects of the system I 
have been proposing in numerous emails. Essentially, the mediawiki 
implementations -- esp. with the current set of plugins -- does not 
allow an external concurrent versioning system, so branching and 
splitting these wikis is much more crude and rudimentary (but yes, 
possible). The point is to aggregate all of these trekkies, right? All 
of the scientists, researchers, programmers, enthusiasts of all sorts 
as they add projects into oscomak formats and then release them upon 
the web. Then, we want to provide gateways for people to tap into this 
knowledge. The important point is providing these gateways while also 
providing the way that people can add to these projects. The gateway 
has to be considered with respect to the basic, fundamental package 
that we offer to the 'trekkies' et al. So if we keep running in front 
of the basic considerations of the interface, then we're screwed, and 
we really need to sit down and discuss the skdb metadata file format. 
This is the file that specifies information like what's in a package, 
what plugins / programs are required to interpret the data, what the 
software can be described as (if it is indeed software inside), lists 
of people or a pointer to a list of people involved with the project, 
information on this particular repo and its history, forums, mailing 
lists, wikis out there on the web, whatever. They *will* make amorphous 
asynchronous networks - this is what the web is already, and it's going 
to continue in the weird (but ultimately very very good and very very 
human :-)) way - but as the social aggregators and programmers that we 
all are, perhaps we can recognize the importance of that gateway, 
before it's too late and we've released a beast that can't be leveraged 
with respect to whatever else we're doing. Re: next steps, while I am 
it, I dropped some notes during my brief lunch period today:
http://heybryan.org/mediawiki/index.php/2008-04-22
For the next steps, there's something that has to be considered like 
debian run levels for the agx-get interface *as well as* some way of 
specifying any sort of run dependencies, i.e. known bug reports where a 
user says "this failed when these two packages were installed, the fix 
is to put this before this other one, or for only one of them to be 
activated at a time, or whatever" - and then let the user via 
disambiguation-options in front of them either on the cli, in the gui, 
over the web, however they are accessing their computer installation, 
maybe (hopefully!) simple parameters to the program, select how to 
proceed, and then get all of the information they need. [The next steps 
include autospec, agx-make, a cupsd-equivalent, and some other programs 
involved in simulation and physical manufacturing, but these things are 
easily thrown in once the fundamentals are in place (agx-get)]. It 
would be helpful if anybody has any insight into the debian run-level 
system. Personally, from my experiences, it seemed somewhat like a 
hack, but I have been coming to the realization that it might be the 
only system that can do the job ... such a hack, but. Eh. Hrm. I'll 
have to come to a conclusion at some point before carrying on, yes, and 
after that it's off to figuring out how to hook the plugins for agx-get 
into the user interface -- the reason these plugins exist is because 
some metadata files (in yaml) will contain information that the user's 
copy of agx-get will not be able to understand and present options to 
users, so the trick is to let them ask the user and so on -- but how 
would this cope with the variety of input mechanisms? Any python-plugin 
code needs to be clearly, distinctly abstracted away from any hardcode 
for io, using agx-get as an interface layer, perhaps via an internal 
messaging system? Then, the cli, gui, or parameters will make the 
selections? Wouldn't this imply a limited number of datatypes? Or would 
the scripts have to offer new modules for each of the new types of 
displays of the options to the user? But then an update to the 
interfaces would imply that all plugins have to be updated too, to fit 
the new environment that users will be operating in. Can anybody see 
the problem space that I am talking about, and is anybody willing to 
help me hack through it?

- Bryan
________________________________________
http://heybryan.org/

-------------------------------------------------------
________________________________________
http://heybryan.org/