general questions about the wiki

[amchagas]

Hello!

First off, let me just say thanks for all the work on Auto-pi-lot, the wiki and the many threads on twitter! I have been reading and learning a lot from all of this. :)

Together with other excellent people, I am running open-neuroscience.com, a webpage/repo for open source projects in Neurosciences. We also host a seminar series in collab with world wide neuro.

Here comes a bit of a long post, sorry!! But I think it is worth writing it down so that other people can also chip in and learn from what we are asking?

For a while now, we have been debating if our hosting system is the best that it could be.... In short, users fill out a google form, some R code creates a markdown file out of it, and the website gets created/updated using Hugo. The whole thing is hosted on GH as a public repo and deployed with GH pages.

It works fine, but it has obvious flaws, like depending on G-forms, the fact that not even we do not know Hugo that well to change the website the way we want, etc. So one thought was to port everything back to wordpress (Open Neuroscience started back in 2013 when all I knew was clicking around in wordpress.com :P ). Which at least gives us more flexibility in terms of more people being able to control it, and to add features via wordpress plugins, even if we have to pay a bit for it....

At the same time, we have been following the auto-pi-lot wiki and love the concept! So one of the things we thought about was porting open neuroscience to such a system. Which them bings me to the following questions (I hope they are not too basic/silly... and thanks in advance for taking the time to read this all the way here...):

• From what I understand this wiki is similar to other wiki systems (wikipedia, etc), which makes the content human readable, but it is also semantic content, that is, data can be linked together, extracted in programatic way with code, etc. So is there a specific purpose of creating your own wiki? Why not host the content on places like wikipedia, or Appropedia.org?
• How easy do you think it would be for the "non-initiated" to set up a similar system? How is it deployed? do we need to set up or hire a server? and how easy would it be to add features, such as filtering/search/tagging capabilities? Also how easy would it be to integrate embbeded videos and format how those are displayed? (I guess my question if more on the side of how easy it is to change layouts/templates, etc)
• Although I think I understand the concept of the wiki and semantic data, I fail to see some applications for this specific case, where we are simply making a collection of projects (sorry if this is a dumb question)

Thanks for reading so far!

[sneakers-the-rat]

YES! Ceci and I had talked a bit about this in the past (and i had mocked up a patch for your tag filtering system so that it was possible to combine multiple tags at once https://gist.github.com/sneakers-the-rat/05760ff45a9c21318a22e4ef5eb6a094 )

I am a big fan of mediawiki + semantic mediawiki, which is what the autopilot wiki runs on, but also see the value in something with a more transparent format like a collection of markup files -- a lot of the same metadata can be done using eg. YAML headers (though not the linked data parts, which are their own cool universe to explore) and the extended universe of markup dialects (eg. MyST). I am also sympathetic to the approachability of wordpress but i have seen it more often than not turn into something that is both limiting and becomes quite hard to maintain through a thicket of plugins and the limitations of the platform, so I would lightly caution against it, though it sounds like you have already been down that road before.

One of the main things that a wiki would do for you is integrate the mode of editing and use, so rather than having specific code to generate the side from a markdown representation, the tools for editing the page are already "embedded in it." This has the additional benefit of allowing you to open up the site to others outside the team to get a broader base of editors -- one of the basic principles of most wikis is "Soft Security" where you give maximal permissions but then also have the tools that limit the possible damage, eg. being able to restore from history and so on.

So to your specific questions:

From what I understand this wiki is similar to other wiki systems (wikipedia, etc)

It is literally wikipedia, in the sense that wikipedia is built on mediawiki :)

which makes the content human readable, but it is also semantic content, that is, data can be linked together, extracted in programatic way with code, etc.

This part is done with semantic mediawiki :) and yes this blend is one of the critical things I think is important, being able to combine structured and unstructured information in a way that can be easily edited by multiple people.

So is there a specific purpose of creating your own wiki? Why not host the content on places like wikipedia, or Appropedia.org?

The goal is to have a set of interoperable and linked wikis - so it's trivial to just take a full export of the autopilot wiki (eg. since everything in mediawiki is a page, you can just take the list of pages and copy paste it into the export page), but in the future I would like to move towards something with more explicit transclusion: being able to represent pages from multiple wikis in the same place, something like what Ward Cunningham is doing with the fedwiki.

I think we need something between the extremes of "everything on one wiki" and "a bunch of disconnected repositories" (which is more like what we have now), and interoperability is one of the key components of that: so eg. rather than standardizing on some markup spec for project pages to integrate what y'all are doing with say openbehavior, that could happen at a "higher level" - either at the level of an interface/tool like mediawiki, or using something like JSON-LD which is what I intend to explore next. I talk a bit about the historical context of this as well as a draft of a practical implementation in my (still not officially released) piece on infrastructure: https://jon-e.net/infrastructure/#the-wiki-way

The goal is emphatically not to make "yet another platform," but to dissolve the notion of platforms altogether by making it easy to set up multiple linked systems: ie. how can we take the work y'all are doing, the work we're doing, and the work any other group is doing and build them into something larger without needing to sacrifice the individuality or heterogeneity of approach and maintaining appropriate social credit.

How easy do you think it would be for the "non-initiated" to set up a similar system? How is it deployed? do we need to set up or hire a server?

I've been meaning to write a wiki page on this for awhile, but it is more straightforward than you would think. Eg. you would rent some server, maybe from some place like linode, which typically will have some software manager that lets you install services - and if they have that, then they will almost certainly have mediawiki. Otherwise the manual installation is pretty manageable - install a LAMP stack, download files, make a database, done.

After that you would just need a few additional extensions (you can see which the autopilot wiki uses here: https://wiki.auto-pi-lot.com/index.php/Special:Version ), each of which has their own installation instructions: usually that's downloading a tarball, extracting it into the extensions directory, and adding a line to the LocalSettings.php file.

how easy would it be to add features, such as filtering/search/tagging capabilities?

Search is built in, tagging can be done in a few ways, either with the [[Category:CATEGORYNAME]] type syntax, or with semantic mediawiki for predicate/triplet links. Another cool thing about wikis is that literally everything that I have done (except for what's in the LocalSettings.php file) is publicly viewable: so anywhere you see something you want to imitate in the autopilot wiki you can just click 'edit' and see how it's done! The meta section links out to the relevant places to find templates, properties, categories, and forms.

It's easy to do freeform tagging like [[Uses Python Package::packagename]] in the body of the text (which on the autopilot wiki is represented as a link to the pypi page - click the edit button to see how that's implemented), but you can also use extensions like Page Schemas and Page Forms in order to make templates that group together sets of properties, as well as forms which give a clean way for people to input them. That's useful for when you have particular categories of objects, like eg. how a 3d CAD model will have an .stl and .step file, and the submission form also pulls in a generic schematic template.

Also how easy would it be to integrate embbeded videos and format how those are displayed?

Super simple, upload a video to the wiki and embed it like [[video:FileName.mp4]] using the EmbedVideo extension. By default mediawiki doesn't let you write just any old raw HTML for security reasons, but it is possible to make it do basically whatever you want, eg. with html templates.

There's also direct control over CSS in a few ways, the simplest being the MediaWiki:Common.css page ( https://wiki.auto-pi-lot.com/index.php/MediaWiki:Common.css ) which i use to embed videos responsively like [[File:VideoName.mp4|class=vid-responsive]]

(I guess my question if more on the side of how easy it is to change layouts/templates, etc)

Yes, in addition to what's described above, the mediawiki template syntax is pretty dang mature (it's what most of wikipedia runs on) https://www.mediawiki.org/wiki/Help:Templates

I use a skin called tweeki which is nice but also is getting a little out of date. you can see its source, or check the skins documentation to see how they're implemented if you wanted to make your own/bring your existing css to the wiki.

Although I think I understand the concept of the wiki and semantic data, I fail to see some applications for this specific case, where we are simply making a collection of projects

Once you get started, the potential will become more evident :).

Eg. on your page now, you have a ton of cool pages for a bunch of different modalities, like projects, packages, learning tools, etc. They're currently organized with a 1-dimensional tagging system (ie. each page has a list of tags that can be used to sort them, but the tags otherwise have no semantic structure, which is the normal way these things work).

take the pycontrol entry. That already has some structured data: [[Author:Thomas Akam]], which would both encode him semantically as the project author and also link to the "Thomas Akam" page. On that page, you could do an {{#ask:}} query to list all the pages that have him as an author, but also say you have a [[Contributed By:]] property where people who help write a page can credit themselves. Both of those link to the same person's page, but in different ways, which are encoded explicitly. The pycontrol page also links out to [[Has Documentatation::https://pycontrol.readthedocs.io/en/latest/]] and could also link out to [[Has Git Repo::url]] or say it is [[Written With Language::Python]] and [[Has Python Package::pycontrol]]. Many of these projects have papers associated with them, so [[Has DOI:]] becomes really useful for being able to do programmatic credit (in the better world we can build, that should count as a "citation").

Pages are cheap on wikis, so instead of jamming everything on one page, you could also make related pages for a given project -- eg. PyControl has a ton of additional hardware, from the main pycontrol page you could say [[Uses Hardware::PyBoard]], and then describe the pyboard on a separate page, link all the other projects that also use it, and so on. Some of these projects explicitly build on one another, so say if each of the projects was in [[Category:Project]] which maybe had an associated template that guaranteed certain basic properties like authors, repositories, etc. then you could make explicit links like [[Extends::]] or [[Uses::]] so those relationships could be made explicit.

Then you start getting into the more interesting stuff like 2nd-order links, like 'find me all the hardware projects by this person that also use this other piece of hardware' or 'list all the optogenetics projects that cost less than $1000 to implement' or etc.

Y'all also put on a seminar series, so that could also be in the same (or a linked) wiki! So on an author page you could also show all the talks that someone has given, the talk page could link back to the project as well, etc.

Then it gets even cooler when multiple independent wikis can work together -- Autopilot could link to open neuroscience for additional context, and vice versa, and if we start extending that out to other groups like maybe some theory journal clubs that talk about some of the projects that open neuro indexes, it would be possible to traverse a rich space of information from theory to implementation. So even if any single wiki is relatively simple (which I don't think this necessarily is, and there are lots of cool things that could be done with the work y'all have already done), the idea is that each individual one can be part of a larger informational ecosystem that has the potential to be a whole lot more useful than the ailing journal system -- but that's maybe a topic for another time.

P.S. no need to worry about the length of posts, i myself am very prone to walls of text lol

[sneakers-the-rat]

Another cool thing about thinking in wikis is that, along the same lines as "pages are cheap," you really remove limitations on yourself as far as what you are representing. While writing, I will always just make [[WikiLinks]] to any topic that I think i might conceivably write about more than once, and even if I don't go and write that page immediately in the moment, the link is made, and so when it is made (by just clicking the link, typing, and clicking save) all those links become live. So as you start using a wiki the barriers around 'what counts' as something we write about start to fall away - you might start by importing your existing set of project pages, but as you're writing you might start making pages for the different related tags you have like optogenetics, and then from the optogenetics page writing some basic description, which could then build out further into some additional methodological caveats... or as you're making your wiki pages, you want to write down your process, so you make a page to describe how you go about adding projects so that information is better distributed throughout your team. You want to remember how you formatted a particular page, so that could get written down too.

Wikis are basically the web we should have had, and once you start using them in one context I have found that people typically start wondering why they don't use them eg. to organize information within their lab, or for themselves, and so once you make one you usually make multiple ;)

[matiasandina]

One of the main things that a wiki would do for you is integrate the mode of editing and use, so rather than having specific code to generate the side from a markdown representation, the tools for editing the page are already "embedded in it." This has the additional benefit of allowing you to open up the site to others outside the team to get a broader base of editors -- one of the basic principles of most wikis is "Soft Security" where you give maximal permissions but then also have the tools that limit the possible damage, eg. being able to restore from history and so on.

This is something that I think is unbeatable in terms of wiki. My original idea when joining open-neuroscience.com was to build a Wikipedia for neuroscience. A hub where people could go look and directly edit content as much as possible (yes, down to the exact part number as done for autopilot box for example). I am a big proponent of automation but this particular point, if the community can get behind it and there are some basic rules (e.g,. stackoverflow and wikipedia itself), beats automated systems.

But then again, I 100% agree that interoperability is needed and might be easier to implement. I think this question is key:

how can we take the work y'all are doing, the work we're doing, and the work any other group is doing and build them into something larger without needing to sacrifice the individuality or heterogeneity of approach and maintaining appropriate social credit

We initially went for Google Forms so that the entry barrier for people was as low as possible and we generated content that was basically trying to interoperate between how different people might organize their projects.

Pages are cheap on wikis, so instead of jamming everything on one page, you could also make related pages for a given project

This is something we would definitely struggle with in any other setting. So yes, treating pages as cheap instead as of "THE ONE AN ONLY" is a good approach.

the idea is that each individual one can be part of a larger informational ecosystem that has the potential to be a whole lot more useful than the ailing journal system -- but that's maybe a topic for another time.

One hundred percent with you. I might add something in the flavor of https://quarto.org/ for publication. I think Elife initially tried something like self-contained papers.

I think one downside of wikis, templates aside, is the aesthetics. I think it's more limited/less appealing than other options. I prefer function over looks, but I am also totally fine with the walls of text.

One thing that I would also like is a level of interaction, something like issues or questions. I envision "an extended system" as something that can function as a hub, connecting creators and people who want help (free-will, collaboration, or even paid consulting). I think there is a lot of value in that (see here by jakob). Currently the closest this connection hub is the Neuromethods Slack, where you can have Loren Looger answering 100 million questions about sensors and what's coming in the pipeline. I think there's opportunity to do better than slack (which, for example limits you to 10K messages). Twitter is also quite good for this and I use it whenever possible.

[amchagas]

Hi again!
Sorry for the delay in replying! lots of new info, things to read and ideas to process 😄

I just had a chat with @matiasandina where we were discussing where to take Open Neuroscience (ON), if it made sense to keep the same system, move to wiki, move to wordpress or what not... But then we realized that this would solve temporarily (at best) a very local problem. Which is all good and fine, but we then would potentially be having the same discussion soon down the line, and more importantly we would not be necessarily adding anything useful in the long run to the Neuroscience community, which is what ON tries to do...

So We had the idea of getting different people that are in the space of “organising” information in Neurosciences in the same “room” to discuss a collaborative way to move forward.

To implement this, we would like to invite you @sneakers-the-rat for a live conversation in a seminar format, with you giving a talk and everyone having a conversation afterwards.

Our initial plan (and please feel completely free to say yes or no and to make improvement suggestions!) would be to have 30min talk about infrastructure for (Neuro)sciences as related to our initiative. This would be followed up by a discussion where we hope to achieve a consensus on what is a good way for multiple groups to move forward and collaborate with structures that make sense for the existing projects.
By hosting the seminar, we hope to get a “digested” version of these many ideas you propose on the link you shared previously and see how they fit with our contexts. Then using the auto transcribe system of online call systems we can have the full discussion pasted openly on GH for instance.

We recognize there is huge space for improvement in the way we conduct science, but we will try to be pragmatic about tackling problems. Initially, we want to focus on the points below. Once they have been addressed, and we understand how this new mode of operation would work, how users engage with it and how we can move forward, we can start looking into other issues.

• Multiple sites/venues that do not communicate in any way (information is “stuck” in each place)

  • Duplication of efforts
  • Fragile in the long term

• Knowledge gets lost (slack for instance archives messages older than 90 days)

  • Informal knowledge hidden from the community
  • Documentation gets old
  • No way to aggregate projects

If you think this is something worthwhile and that could be interesting for you, we can arrange a time/date that suits you best and start compiling a list of people that could potentially be interested in learning and contributing to this.