ting13, sunday 27th of March 2005, 18:00 GMT (19:00 CET)[edit]
See also ting13_document on the article page.
Page copied in from moon-edit, server: is-root.de, port: 32123,
ting13_talk
Participants
- ma: Mattis Manzel
- mu: mutante
- lk: Lion Kimbro
ma: heck, I forgot the ting. 22 minutes late, but nobody around. But as it's a bad lucky number anyhow, so let's make it up to ting14 ;)
mu: hello, we can now include any RSS feed into the wiki. (even those containing pictures :O)
ma: jo
- freu* and they are fast like hell, true?
mu: they are fast because it uses "caching" and keeps copies on our server
ma: and I do not have to force a refresh.
mu: additionally the mediawiki has a cache. So both, the mediawiki and "magpie",which is the PHP class for reading RSS-feeds that we use in our custom extension, have a caching function enabled. Then there could be even your browser or router or a proxy in between also cache (depends).
ma: Seems like a special easter-egg. Its very good. What about sorting by editing date on mixed recent schanges. For some feeds that would be useful. Even better when for example seeing whenin what sequence german mainstream media reported on an event.
mu: Cant get the date extracted from newsfeeds. Every kind of newsfeed uses a different variable name for the date and has it in different format. We can do that only if all neighbors use the same wiki engine or format of their Feed. Or we would need many different tags, not only (rss) but (rss-usemod) (rss-mediawiki) etc etc...i dont like that so much yet
ma: :( but it will come, Communitiy-wiki has usemod and prowiki (Gründer-wiki) merged by date.
mu: I like the Feeds/CCC page, because when they all start to use Mediawiki, it is very nice to integrate ALL local CCC-groups and their RecentChanges. A classical example of a WikiNode but including (some) content. (De)-Centralizing.
ma: I export here and now btw.
mu: Source for finding more RSS-feeds:
german: http://www.rss-verzeichnis.de/
english: http://www.syndic8.com/
ma: I started noding Linux-wikis. Might become many.
mu: I noticed how you noded the CCC Wikis when adding their feeds ;)
There are some categories that, when dropping in an un-noded wiki one should make leave the url as (still) lacking a node on a well-noded neighbor at least.
- university-wikis
- city-wikis
- Linux (or any other OS-specific)-wikis
- Discordian-wikis
- Band-wikis
- (any subcultural genre)(eg. PunkWiki, GothicWiki, ReggeaWiki, Geeks & Nerds, Hacker)
- gift-economy, alternative currencies - prtty big yet
- anything that can also make a "webring" ,like the traditional html pages with their "webring" logos/html snippets
ma: Having this list somewhere with a link to one of the nodes would be of good help. Best on wiki-nodes, lions taoriver wiki where it all started. The faq's there are important and have to be tuned.
mu: One could maybe publish a feed that includes the RecentChanges of a group of noded-wikis that belong together. So a subject-specific node could have ONE feed including the last 2 or 3 changes of each (sub)-wiki/node-member.
ma: yeah, der totale Bregen! Maybe the node-wiki-for-...-wiki could be helpful ther. It feels like that what I had intended when I started making them. But it's lame, as it predefines a function in the name that could (should!) dynamically shift.
mu: i would like to call all wiki people to follow the same standard (a interwiki standard,across wiki engines) ,so that all variables used in RSS feeds (especially in RecentChanges) have the same names wikilandia-wide. (especially the DATE variable and its format would be nice to be unified wiki standard. thanks. mutante ;)
ma: very important. With a good wiki-node network, we could convince some people to adapt to it. They would see advantages in that, up to now wiis mostly saw themselves (kidding)
mu: by the way: "13" is not an unlucky number ;) EOF Ting13 ,March 27,2005 (K)
mu: daamn, the pope's voice (just some weird noise/crackling/krächzen) (poor guy),dangerous that Ratzinger has more power now mu: even my roman-catholic grandma doesnt like Kardinal Ratzinger
ma:exported :) (my neighbors had it too here, and bells, you can't imagine, they ring crazy.) ... religion-wiki: some people there here and now, could be dealt with there, another category btw. ... ma: statistics. Some mediawiki have very chic ones.
mu: haha, it'd be funny to node the christians with the satanists (both ways of course;
ma:they are supposed to all coexist on religion wiki. By idea it's the far biggest one of mine. ;)
mu: Do you know the discordians once started a mass-mailing campaign against Yahoo!. They asked to be included in the list of "serious" religions, rather than in category "Parody Religions". And they started this "serious" campaign for it.Hehe , i thought it was funny;)
Idea for a name: TheosophosHive TheoNode TheosophNode ,something ,didnt the Theosophical Society try to include all those religions..
ma: Gods-wiki :)
mu: WikiHeaven+WikiHive=WikiHiven God+Wiki+Node=NoDogWiki GOD <> DOG <> DOG ON <> SIRIUS <> ARE U SIRIUS? ((Category:Random Bullshit))
ma: Nirvana-Paradise-of-Gods-wiki It should grow.
mu: like a seed
ma: Couple of hundred nodes to be made, we need a wiki-noding flashmob.
mu: Everthing towards automatic WikiNoding is the same tools that WikiSpammers would use ;) That implies giving them the idea /tools to spam their content on the nodes (watch out)
ma: I wandered about that already, does it make it easier for spammers. Important, I't dislike having killed wikilandia, know?
mu: yes, we do the work for them of finding identical pages that they can spam in identical way(with a script).
using the rss feed concept to include content of other wikis doesnt include any spam risk though. if we would provide the node feed, and every wiki could include feeds ,would be nice. But not all wikis can include rss-feeds yet. I think we are the first mediawiki to do that by ourselves.
ma: man, you gotta talk to lion. Him and crypto are cooking something, it seems.
mu: please just show them the wiki page of this Ting. Hopefully lion comments on it, later in the wiki.
ma: I think so. I posted on onebigsoup, but none around. It's really great to be able to send out a url of an ongoing conversation. People can drop in directly.
mu: ok, nice, but gotta leave the ting now for hygiene / food / moving .(moving out of this place soon)
ma: me too. cu, nice ting, as usual.
mu: cu, you save this one. later on efnet
ma: *** spam is such a touchy thing. We shoul not for a secon think we're safe now with th spam-protection systems. I understand that the wiki-nodes are a danger. I t would be better to base it on feeds. Lion was right from the beginning. *** Hola Lion.
lk: ARGH! I'm too late. {:(}= I had forgotten the time and stuff.
ma: I missed it too :)
lk: Scanning over it,..
ma: mutante went for food. jroes is sad with his mac. unregarded moon-edit. Should I buy a mac? I have to get a new laptop.
lk: Well, you're talking to someone very biased. No, don't get a mac. Run Linux on a PC. {;D}=
ma: k, told mutante you're here.
lk: I would like to talk with him some time.
lk: There was no summary document! Argh! {;D}= I wasn't here to do my live summary.
ma: exists, un-touched, summarize please, would be very useful and interesting.
lk: I have two things to talk about, let me pull up another ME so that I can record it on the table.
ma: I told the espians too. exported again. (what a powerful command scripts enter command, svsavetxt - public. It's so cool. Automatically every theree minutes would be useful.
lk: I'd like to put on the table two items: A structure and method for these meetings. And then I'd like to talk about WikiNoding, and concerns I have over imposing values. There may be other things, I'm just not thinking of them yet.
lk: Is there anything you would like to talk about?
lk: I mean, we can talk about whatever, whenever, but- well, I'll explain what I mean in a moment.
ma: seen aour Feeds section on s23-wiki?
lk: No; But I'd love to hear about it. {:)}=
lk: Is that: http://is-root.de/wiki/index.php/RssNewsFeeds ?
http://is-root.de/wiki/index.php/Feeds
ma: Problem (for some) is: they should merge and list by editing data. recent changes of our neighbors for example. just liek the recent near changes on community-wiki.
lk: <nod> on OddWiki, you can put an aggregation of feeds anywhere. <nod>
ma. recent near changes on Mattis-Manzel-wiki is what I tried on oddwiki. Merge slow, but very informative for me. all saves a lot of time for mne checking all the small wikis.
lk: It would be very useful if we had an event system between all the wiki. Perhaps something based on JEP-0060 Jabber. If anything changes in a wiki, then the other wiki receive a notice. That way, you don't have to keep polling, and you can maintain perfect caches (always up-to-date) of RSS feeds. As a side benefit, you can also keep in perfect step with another wiki: As soon as a change happens, download the new version of the page, and you're in sync. (CommunityWiki:DistributedEditing) It would be very fast. MoinMoin has plans to implement an internal event system. It could be extended with a plugin to work with whatever network comes out.
lk: Do we have more to say on this subject?
ma: there will be more. :)
lk: <nod> {:)}= I mean, right now: Do we have pressing concerns on the subject, or news to tell, or something. Because, I'd like to talk about structuring these meetings, what we gain from that, what I believe we can do with them, things like that. {:)}=
ma: what makes the difference for me, sometimes, is the sheer feel that someone listens, it inspires somehow. I think it's similar to you. So just blast, all out, and things can be condensed later. It is basically different from irc, it it mo chat. Not only. I wish more people would see that.
lk: What do you feel are the major differences between Moon Edit and IRC?
ma:
- the contents is not transient and can be reworked
- you can correct yourself and other simultaneously to other people editing
- you can copy and paste good contents to a -document page.
what does suck for now, you have to sign, there is no date-stamping (no real prob)
lk: (I would want to note- you can also log and save IRC conversations. We have even done this before, automatically, to wiki.)
ma: I would note: nobody does so.
lk: I think that's only because our bot is not in use right now. When we had it, we did it all the time.
ma: IRC rules on bots and other things. Combine, use simultaneously, generateur poitic, skype, irc, moon-edit. ;)
lk: Anyways- what I wanted to talk about wasn't so much the *technology* choices behind our meting, but the purpose and method with which we do our meeting.
ma: what I did was starting on regular jamming here. If a song turns out, ok for me, I might have ideas, but am not the "composer" / the "songwriter" type. I'm a bass-player.
lk: I suppose what the thing is for me: There's an economy on real-time interaction. That is, when we sit here talking face-to-face (in a way,) in different time zones, and furthermore- all together, all synchronized-- the thing is, there's an economy on that. It's not "cheap." It takes a lot of effort to get lots of different people into the same place, the same time, etc,. etc., etc.,. So, I feel that there has to be a powerful incentive to do so. (So, I believe we need to structure our meetings, so that we can make best use of shared time together.)
ma: agree, it's pretty bold to call in people for a ting. There should be at least some sour cucumbers on the table ;)
lk: <laugh> {;D}= <g>
lk: but Mattis, I don't know what that means! {:)}= What are: "Sour cucumbers on the table?"
ma: Inviting for a party without cucumbers, well. I'd like pre-structure and tried to copy in relevant passages for ting-preparation from earlier tings. xtof ws good on preparations and structuring, the espians too. Dunno what we lost with ting 5 qnd ting6 really (apart from the link to tom's javascript version).
lk: In CommunityWiki:RobertsRules, I described a stripped down procedure for meeting, that is, I think, very simple, and does most of what I think is important for our state in growth.
lk: My feeling is, if people believe that it's hard to meet, and that not much useful comes from it, that they will just stop coming. My feeling is that it needs to be an economic thing, and my guess is that this is what happened.
lk: I should move my stripped down "Roberts Rules" to another page,... I'm trying to think of a good name for it..
lk: Let me describe it, very fast, here:
- Upon meeting, people gather, and say briefly what's on their minds.
- The ideas are collected onto a "table." Anybody can add to the table, at any time, if they have an idea that they want to talk about, but think that now might not be a good time.
- Somehow, the members pick an item to talk about first.
- Everyone talks about it.
- When it feels done, (and discussion starts groping about into tangents,) it's over. (Interesting tangents may be added to the table.
- Ask everyone if there's anything to add or drop from the table.
- Go back to "pick an item to talk about."
ma: the talbe about ideas to be dicussed but are not in-time is very good, Almost a third window. You can merge conferece calls in skype I heard.
lk: I'd just keep it as part of the document window. If people aren't using the document window, keep it at the top of the page: It's critical that everyone can see it and has easy access to it- both for reading, and for adding their own things.
ma: no third window, right.
lk: Let me summarize for the document window very quickly...
Ma: wiki.
mu:hi, whats new ,summary?
ma: mu, cool. you ,mu, gotta open a second moon-edit window ting13_document, lion summarizes there.
lk: mutante, good to see you, nice to meet you- yes, please, check out the sumary in the other window.
mu: mattis always says we should talk *g
lk: Well, I feel he is right. {:)}= But, please; Take a moment to get caught up. I was talking about the structure of our meetings, the economy of time, things like that.
ma: this is the magic moment, this one :)
lk: Well, I certainly hope so. I'm enthusiastic about meeting mutante, that's for sure. {:)}=
mu: well,actually i used more wiki ,rather than IRC (which i have been addicted to in the past) because it has a different non-realtime approach. Not having to be online at the same moment in time seemed to give better results when working in actual projects. The Ting,when used for chat is a bit like IRC for me. But i would like to use it for programming /scripting rather than talking. The wiki-tech /wiki socials discussions could be in the Wiki itself on Talk pages, and dont necessarily be in realtime even though its nice to see (and hear ;) others typing.
I would like to use it as an extension to IRC. When somebody asks something on IRC help channels, they usually ask people to paste to pastebin.com or similar. It would be really nice if in this situation MoonEdit would be used. Then the people helping can edit in his file/script/config/whatever together with him. The best way of learning That would probably need an easy bot command for people to upload their text file to ME server (and unfortunately having to download the (non-free) client. I hope the MoonEdit Liberation Front gets a lot of support in making a free clone.
ma: remember to keep the contents of this document exportable to the www.
lk: My personal feeling, is that the interactive quality adds something that cannot be met in non-realtime interaction. Certain discussions will happen x100 faster in realtime, than in slow messaging over wiki or forum boards.
ma: the typing sound rocks! It actually would be good to have a second level - irc - to talk freely, knowing that it is (halfways) transient and doesn't get exported to wiki..
lk: JulianKrause is working on CoEd, a replacement to MoonEdit. I think the most important thing is choice of protocol and algorithm. He's studying the REal-time collaborative editing systems paper. He hasn't been working on it in the past 2, 3 weeks, though.
let me go back and read
lk: My feeling is that IRC is frequently not productive not because it's real-time interaction, but because it is unfocused, undirected, unstructured.
ma: well and why? Because people know that it's blown away in a minute anyway,
lk: Perhaps, but I think the important things are that there's a Table that people have access to, and a process around using it, so that we make efficient use of time.
mu: lk, i said earlier i would like to see a unified RSS structure for Wikis, across the Wiki engines. the Date field is always named different and different format, giving me trouble. I can only adjust the RSS extension to Usemod OR Mediawiki OR other feed styles at once, or i would need several different parsers and tags like <rss_usemod> etc
ma: differnt tags would be ok for now, I think.
mu: And about wiki-noding: I thought about publishing an rss-feed consisting of the RecentChanges of all Wikis inside a Node its like the webrings worked in the past with tradiontional static html. Those Wikis that belong to the same topic, are noded together and there could be ONE feed containing their changes. So one would get all feeds with a script,stick them into one feed and offer that feed. If all Wikis on the node would be able to include RSS feeds, they could all include this (centralized) feed into their node page. (RSS approach doesnt come with Spam risks) why do you have two pages anyways ;? i see, youre already taking this professionally ;) Ok, im adopting /learning your structure, i havent attended many Tings so far. What else are we talking about today. Do you have any questions on our Mediawiki extensions?
lk: (wait, wait, wait- this is a ton of stuff at once) This is where I think, "If we're going to do this fruitfully, we should structure our conversation." Well, wait- mutante: Can you run two ME's at the same time? It occurs to me, you can't see the Table, because it's on the other page. Should I move it to this one? Document Mode and Thread Mode, sort of? The Table is at the top; It's the things on the to-talk-about-list. Well, ther's a lot of work to do,... {;)}= i mean: If Ting sessions are going to be long and unfocused, I don't know if I can realistically attend every Sunday. (Not to be forceful, but this is how it feels to me.) I'm *really* interested in having a real-time interactive session with other people of similar mind. But, I don't think we can just keep going and going, without some- you know: we're going to have like 5-10 people here; There are many time constraints, things that have to happen. (I feel.) (I do take this somewhat professionaly, in the sense of wanting to be efficient and things like that.)
lk: Are there things that you specificly want to talk about? That, if you left, and you didn't talk about, that you would be dissapointed about?
ma: make two windows visible on yur screen, drag them.
lk: argh...! This is why IRC is so good,.. Because there's a flow to the conversation, rather than weird interactions across the space of the document...
mu: i have two pages open , Do you have any questions on Mediawiki RSS integration
lk: As far as I know, MediaWiki supports RSS feeds; I don't know much beyond that. I guess: "no."
lk: The things I wanted to bring to the table, were: Structure and method for these meetings, Wiki-noding issues (such as: being values neutral, respectful of the communities we encounter,) -- those were the things I wanted to bring with me, to talk about.
ma: agree one shouldn't overrunn wikis with dozens of neighbors as I did during the last few day, people might be confused. But on the other hand: one should (as it's for a good purpose).
mu: some Wiki communites didnt seem to like being noded. Like the Cologne CCC wiki once called us even Wiki spammers, because we back-link to our own wiki.
lk: Well, I think the way it's been happening, YES, it has been wiki-spam. I think the approach is dangerous, being taken right now.
lk: In particular, finding the wiki of Christians, and then linking them to, say, a United universal religious wiki-- I think that's just begging for trouble, and (I don't like using such strong language): an absolutely terrible idea.
mu: hehe, but the thought of linking christian to satanist churches seemed funny to me earlier,i admit
lk: Well, it's funny, but it'd destroy WikiNodes as a concept.
mu: why, i mean, you said being neutral.
ma: lion's right, driving it far, but not destroying the concept.
lk: Not so much "neutral," but "respectful of community concerns."
lk: A Christian wiki should node with related Christian wiki. And we have to be careful about knowing what that means. When we don't know, we shouldn't do it.
ma: It's exactly that respect stuff. When I thing about the neighbors I would sign on s23, I should think, what is it I a n d the community like. I shouls not try to spam my wikis / destroy the concept.
lk: I mean: We can believe for ourselves that religions should be united, or something like that. But, they don't necessarily see it like that. If we force this on them, then they are going to reject it, and it will be a negative for WikiNodes: Nobody will want to have anything to do with anything remotely like it, and a good idea will be delayed by 10 years.
mu: maybe its better to start off with subjects like noding LinuxWikis, which is purely technical and the same subject, like all those local LUGs (Linux User groups). If no religion is involved its not so dangerous, people dont get mad so quickly. I think most of them would like being linked to each other. But actually you would have to treat it like a webring. That means every member of the ring/node is being asked if they want to join it or not.
lk: I personally feel we can be a little bolder than asking: I think that if we just ask, we have two problems: (1) People can't see the big vision- you have to explain it, rather than just showing it. (2) People will just not respond to random requests for some weird "wiki nodes" that they don't understand. I've seen positive response to WikiNodes, when it actually connects groups, and when it's respectfully done.
ma: Linux and LUGs good - people who can probably gasp wiki. Made a Venezia-LUG-wiki.
mu: then you can make it "opt-out" solution. in other words (if you want to be removed from this WikiNode,tell us)
lk: BeBold is a proud and time-honored tradition amongst wiki. {;)}= Nonono- They don't have to tell us. They just erase the page. Job done.
lk: We are not "central administrators of the WikiNodesNetwork." The goal is that they just maintain it themselves.
ma: wiki-noding-party, wiki-noding-flashmob. Organize think where and when and who and what and than go, a dozwn people node a complete hive in a day. Gently, so that everybody think: "Hey, cool."
mu: we would be kind of central-admins if it comes to publishing feeds consisting of combined RC-feeds of other wikis mu: also RSS fees can have different licenses by the way (copyright issues unclear when integrating into wiki pages)
lk: Right; I don't think we can do that.
lk: We absolutely cannot be arbitrators of what wiki are going to know what other wiki, and what they can see. That's totally not our business, and we will be kicked out of everywher we go if we attempt to do such a thing.
ma: decentralize it ;)
lk: To do something like shared-neighbor feeds, the technology we need is SemanticWiki, or metadata-in-the-wiki, or however we want to see it. Then, we can go on a wiki-noding spre (again) for the wikinode-in-metadata, and make cool tools that aggregate a neighborhood's changes and show it to people. As people see these things, they'll make them their own.
mu: if we would stick to Mediawikis (just as an example because i know it) we could read from other Special pages,like Statistics. and make cool Wikilandia-wide statistics (most popular page in whole wikiland) ,I love statistics ;)
lk: Argh; I feel like we're losing focus again. Sorry. {;)}=
lk: So, basically what I'm saying is: We need to be respectful of communities, we need to not be central-admins. We are idea spreaders, but we're not owning their wiki, the connections between wiki, and trying to make people organize the way we want them to organize.
mu: we are asking them to stick to some kind of new wiki-standard for easier interwiki-connections in between Wikiengines?
lk: I think that *that* sort of work happens at the developer-engine level, but not at the communities level. That is, in an effort at interoperability, I think we should talk to the MediaWiki developers, rather than individual people in particular (say) wikibooks. Like, the Lucid dreaming book: we don't go to that comunity and say, "Hey, we think MediaWiki should have these features." Rather, we go to the MediaWiki devs, and say, "Isn't this a neat idea?" they are held accountable by the user community.
mu: actually it's at the level in between developer of the engine and the community. It's the level of the admins installing the wiki enginges. They could install certain extensions/plugins/ use the same configs etc..
lk: Ah, good point. Really, it's all three. The main thing I want to say is: I don't believe we should use WikiNodes as an advertisement of our ideas for how to maintain, write, wiki software. I think WikiNoding should be strictly wikinoding. I like to seperate ideas into different lines. (Like, paragraphs on a page, and such.)
mu: i agree, Wiki-nodes shouldn't be used to promote our ideas for Wiki-technology. Personally i have more contact to the developers than the actual community though. ... It seems i am more interested in the technology itself (making new extensions and stuff) than the sociology, which you guys are specialized in.
lk: The most important things technology-wise, it seems to me, are: Metadata publishing from wiki, and use of event sytems. From there, most other technologies magically spring out.
lk: But, okay- it sounds like we have some agreement her.
mu: Can you tell me more about wiki-metadata? It seems interesting. What kind of information would you want to put in metadata?
lk: I don't know if it's so much metadata, as *machine-readable* data. So, you should be able to, in the WikiNodes page, say, "these are the URLs of the WikiNodes of my neighbors," in a machine-readable way. You should be able to make a series of web pages that says various tidbits. ... Let's say you had a wiki about baseball players. You should be able to have each page for a baseball player also contain machine-readable (easily parsable, context-free parsing, yadda yadda) information on the stats. Then a program can scan through all the pages, strip out the metadata from the human data, and do useful things from it.
mu: so the wikiengine would append an XML header to each wiki page containing ,lets say Access Stats
lk: Perhaps! I'm not so interested in the particulars of what colors the wires are, where things are, how they're arranged. I'm more interested that we have the capability for users to quickly and easily put metadat in.
mu: i am the guy who is interested in that part and need people like you to get the ideas to do it.
lk: {;)}= I do confess some interest in it, but it's more important to me, that the technology is implemented. Because you can do WICKED COOL THINGS once you have this.
mu: which wiki engine do you personally use?
lk: I know MoinMoin, because I'm a Python guy. I know there is weak support for this kind of thing in MoinMoin. I know the MediaWiki guys are talking about some formats; I mentioned in the last ting,... (can look up the URL)
mu: it seems possible to me to hack the mediawiki to add the access stats for each page into a header (or footer), in a simple format, like comma seperated values problem is all those different wiki engines would need a custom plugin to deliver the exact same format
lk: here it is:
http://meta.wikipedia.org/wiki/Field-value_pairs
mu: that approach seems good, they are far ahead alreay
lk: Should we talk tech ideas on implementation right now?
ma: yes
lk: I would think that we'll be having a hodge-podge of formats, re: metadata for a wiki. For example, two common formats are RSS for the news, and plain-text listings for "list all the pages of this wiki." I suspect that statistics would come through an XML format, and be addressed by a special-form URL. And I suspect the page metadata, user contributed, would be an XML or RDF form, addressed through another special URL, when a machine comes visiting by. ... For example:
http://example.net/wiki/WikiNode&format=usermetadata <- returns RDF/XML of user contributed metadata http://example.net/wiki/?action=recentchanges <-- returns RSS feed (...etc., etc.,.)
mu: aha, that would come down to just making the RSS feeds themselves be editable by users,too. So the users would also write all the content for the machines.
lk: (Well, I hadn't thought of that, but that's something that could be done; Sunir Shah wrote about that idea on MeatballWiki:DigestedChanges )
ma: cool
lk: oh, no, that's not what I meant- what I meant was: ... Pretend we're writing WikiNode on s23:
Welcome to the`s23-wiki: wiki-node`! Blah blah blah blah blah.
Our neighbors are:
* community-wiki * [.... ...]
Welcome to our wiki!
- MACHINE-CODE (XML)? BEGINS
- wiki-metadata: http://...(s23's address)/.../AboutThisWiki?render=machine-form
- neighbor: http://</neighbor>
Well, it could be XML, it could be whatever. Here's my argument against using XML:
- Most users want to write XML as much XML as they want to write HTML.
- That is, we want users to write the metadata. It should have a wiki-like syntax.
- Perhaps it renders out as XML for the ?render=machine-form version.
mu: then i differ from popular opinion in this point, because i always like to write html/xml and i see learning Wiki syntax as not making so much sense, just learning another syntax.One as hard to remember as the other.
lk: You do, because you're a developer. But most users, I guarantee you- it would be a very different wiki-world if everyone had to write HTML to write on any wiki.
lk: I think we want something not-as-powerful as XML, but that's super easy for people (who don't even know what XML means) to add meta-data with. (That's why I favor the wikipedia proposal for field-value pairs.)
mu: The string "Our neighbors are:" in the human-readable format could also be machine-read. Doesnt matter which strings as long as they are the same everywhere. So mayb you dont need an extra Machine Code block. but just make users write the Node with same syntax
lk: I think we'd come across styling problems, and things like that. I think people want to custom tailor their presentations to their wiki. Yeah, I think that's too much of a burden on WikiNode writers, to always write them the same way, on all wiki,... I mean, I understand that it's possible, but, I mean, personally, on my own wiki: I wouldn't want to use machine identifier to be the same thing as human identifier. .. Ideally, you just programmatically generate the presentation from the metadata.
mu: Would you want to hide the machine code block from a human reader?
lk: I don't know; I think you definitely want to segregate it. Perhaps at the bottom of the page, perhaps on a seperate view of the page, perhaps only in the edit-page view; I don't know. That's something I feel people need to explore. But, I wouldn't just include it as part of the text of the page.
mu: one could extract all URLs from WikiNode pages automatically already. All URLs on WikiNode pages are "Neighbors"
lk: Yes, but then you'd get a lot of extraneous stuff- for instance, we frequently link the phrase "WikiNode" to the WikiNodes FAQ. Also, there are many links to internal pages on the wiki.
mu: right, all those "powered by" links..agreed
lk: <laugh> I didn't think of that, but, yeah.
lk: There's a lot of decisions to be made in this space, I don't intend to come to answer them today. But, I think this is a seriously kick-ass thing, and will really revolutionize wiki space. Because, there will be all these programs slurping up data from the wiki.
mu: I suggest we are making a wiki page to define the syntax for the machine readable WikiNode format.
ma. did some promo for ting 13 on #esp and #wiki
mu: Suggesting "Machine readable WikiNode CodeBlock syntax" for ting14
lk: (Do you know about the WikiGateway?)
mu: No.
lk: This is Bayle Shanks' baby; What it does is internalize conversion logic between different wiki. If we get a machine-readable form from different wiki, it's just a matter of matching models: Pulling the data out is then actually no problem. All you have to do is standardize on the *model.*
mu: i like it! Lets make the standard ;) The "Code Block" approach is nice, it can be used in any wiki page for many other ideas in the future.
lk: Hmmm..! Do you mean something like: sticking a geek-code-like block on people's wikinodes?
mu: hehe, yes, the GeekCode came to my mind right after you started typing that block
WIKINODEBLOCK BEGINS neighbor: URL neighbor: URL neighbor: URL title: FOO WIKINODEBLOCK ENDS
mu: i suggest calling it "InterWiki Code" or just "WikiCode" WikiMachineCode or something, I see more purposes that just WikiNodes in the future.
ma: wiki-code is cool.
lk: Okay, but I want to put some PR restrictions on how we go about doing this. {;D}=
lk: You are quite right. This is the basis for a large architecture.
lk: We could use YAML. (It occurs to me.)
mu: Machine Readable Wiki Markup Language (MRWML)
lk: I like the name "WikiMachineCode"
lk: But is it really a markup? i think it's just a block of text; Markup, I think of "putting tags inside of a human-readable text." This is more like a UCP code, a bar code stamp.
mu: ok ok;) the users dont want tags ;) but its made for machines ,right? *g* and parsing tags is easier for machines ,they dont like whitespaces and end of lines ;)
lk: I just think: For this to be useful, it needs lots of data, which means that it needs to be *easy* for people to write. Like, SUPER-simple. It also needs to be networked. That is, it has to have pointers from blocks to blocks. We could say, "Just one block per page," and, "The only data type is string." Things to limit it, and make it super-simple.
mu: agreed, but the users must use only one definition per line then
lk: Let suppose you wanted a multi-volume epic as the argument to a definition. In that case, give a URL to another page in the wiki, and make it part of the "we-keep-this-in-our-head" standard that things with that key point to big blocks of text found at another URL.
mu: user acceptance / being super-easy , would mean being close to the wiki-syntax they are already used to. Unfortunately different wikis mean different syntax. Even though , they almost all have [http:// Description] linking.
lk: Mm, true, good point.
lk: Well, I think just about every wiki has a way of commentin g blocks of text out. There are two forms for commenting text that are common:
{{{BLOCK BRACE this is a comment this is a comment }}}BLOCK BRACE (comment ends)
or:
- preceeding-text# This is a comment
- preceeding-text# This is a comment.
We can combine them together by making a block brace equivalent to a preceeding text (ie: "#") situation.
mu: Could you live with the whole block being ONE tag like:
<machinecode> neighbor: URL neighbor: URL </machinecode>
?
lk: The problem is that, in many wiki, that's going to show up in the displayed page. I'm thinking:
- <machinecode>
- neighbor: URL
- neighbor: URL
- </machinecode>
The advantage here, is that no matter what they use for commenting, you can do it okay. Let's supose they used "@@" as their comment sign:
@@ <machinecode> @@ neighbor: URL @@ neighbor: URL @@ </machinecode>
(when you scan out the page, you look for what preceeded the "<machinecode>" tag, and say that that is what you ignore.)
mu: Give the users the choice whether to hide (with their local comment options) or show the block, the machine would only need the tag itself, rest around would be optional. Yeah.
lk: This would work in *all* wiki syntaxes that I know of. You could hide the machine-code from the user, and reveal it to the machine-parser, reading raw page contents.
mu: the wiki admin could even decide whether he wants to put the <machinecode> into his page header or into the body, or if we lets his users put them manually into wiki pages. The machine reading it wouldnt care,where it finds it in source. it could also be displayed black on black background like those people trying to fool google ;)
lk: yeees. :)
lk: If you think about it, we get three data types, "for free." We have *strings* (obviously,) *pointers* (via URLs,) and *lists* (in the event that a key is repeatedly defined.)
lk: <laugh> Well, you could not display the machine data *at all,* when it's commented. Just show it in the raw page, and user pointers to raw pages in URLs. (That is, when you are pointing to the machine data on another page, use the point URL of the raw form of the target page.)
mu: yes, it could come AFTER the </html> tag even.
mu: any other "variables" besides "neighbor" that could be used in the machinecode?
lk: OH TOTALLY!
lk: Totally totally totally!
lk: Here's what you do:
AboutThisWiki
-- human data: tells about the wiki -- machine data: tells the name of the wiki, points to the WikiHomePages of the regulars of the wiki -- points to the RSS feed for the wiki -- points to the Interwiki table for the wiki:
InterWiki
-- binds all the names to the prefixes of the target wiki
User Home Pages:
-- point to the FOAF information for a user -- tell the user's name -- tell the users other wiki home pages (also with machine-read data) <-yes, thats combining it with InterWiki
Wiki-node:
-- Point to the AboutThisWiki page, so all the info from there is acessible from here
mu: I suggest we include a syntax for InterWiki aliases. A centralized (sorry) (just a list) of Aliases for the Wikis. So we can link with short InterWiki links like EmacsWiki:HomePage S23Wiki:HomePage in ALL wikis the same way. That would mean asking the wiki maintainers to update their "intermap" files (if they have) and following a standard when giving out the aliases.
lk: I'm sorry, do you know about Local Names?
mu: I think the same concept has just different names on different Wiki engines. What i mean is a list of other Wikis URLs, its the "Intermap" file in Usemod wiki.
lk: (The only people who have also thought about Local Names are the Pet Names people. I've never discovered anyone else doing it.) ... Personally, I think a universal intermap across all wiki is totally not going to happen. (And, we can do just fine without it.)
lk: I'd want to keep this super-simple first; I would want to offload making neat shortcuts for links into the future, for tools and stuff to handle. WEeell...
lk: (thinks)
lk: Because we want it to be easy for users to make links to other pages, and pages on other wiki. Perhaps a standard part of this should be: "Here's how you find the Interwiki bindings for this particular wiki. Standard issue. If you're not following this form, you're not doing the Wiki-Machine-Code standard form."
lk: Hmm, but you have to locate the standard page. That is, if some parser gets a URL, it has no idea of how to find the InterWiki page definitions from that URL. Well, here's something we could do:
lk: If you want to use URL shortcuts, then you say this:
<machinecode> URL-SHORTCUTS: http://... <- this page includes a block of URL shortcuts </machinecode>
mu: *(widely used URL-Shortcuts can be found here (links to WikiPage for InterWiki standardization)
lk: Yeah, but we need that in a machine-readable form. That's good for people, but it needs to be used in the machine-code block.
mu: interwiki_index: http://
lk: We also need a way of saying, "I'm using shortcuts." That is, something like CommunityWiki:MattisManzel -- it needs to know that that's a URL, not a string. So we say, "this is the standard linking format". Similarly, the interwiki_index needs to tell what the naked pattern is, for when you aren't targetting a different wiki. (Rather, naming a page on the same wiki.)
mu: since the GeekCode block is quite popular, maybe we would get some acceptance/attention calling it the WikiCode block
lk: But we shouldn't call it "WikiCodeBlock." Because there's no reason you couldn't use this on normal web pages, threaded conversations, wherever. You could use this anywhere.
mu: aren't we getting to close to re-inveting RSS (XML based syndication) then
lk: hell no. {:)}= This is so very different.
lk: I mean, you can't just start typing in baseball player's statistics on a wiki page in RSS. It just doesn't work, in so many ways.
mu: ok, lets get back to the WikiNode example then ,and stay simple like you said, we should first define our standard on some wiki page and give it a name. mu: then we can start using it on our own wikis and test a parser for it,before putting it on foreign wikis.
lk: I think we already made it up, we just need to type it out. {:)}=
lk: Yah!
lk: I mean, do you realize what you can do with this?! You can write Python code like:
import markupblocks
d = markupblocks.get("http://example.net/wiki/WikiNode")
for neighbor in d["neighbor"]:
print neighbor["wiki-details"]["title"]
That code would systematicaly visit every wiki, find the link to the "wiki-details" page, and then look up the "title" entry on that page. (Like "AboutThisWiki" in human readable form.)
You could even make it so you could *ADD* data, provided the pattern for finding the edit link pattern or process info could be found on the AboutThisWiki page.
ma: hugs mutante and lion.
lk: Just amazing things that can be done with this technology.
lk: Are you leaving right now?
mu: just takes a break enjoying the new possibilities that come to our mind (and licking his fingers from chocolate)
lk: {:D}=
lk: Okay, I need to go right now. I think the standard as described here is excellent as it is: Well, allow me to write out what I believe it is:
A block begins with any number of characters, and then the text: <machinecode>
The characters preceeding <machinecode> are taken to be the comment characters, and ignored in following lines.
The block ends with: </machinecode>
Lines consist of key-value pairs, of the following form:
KEY: VALUE
All keys are interpreted and typed as strings. All values are interpreted as strings, and can be viewed/typed as strings.
A value that is a URL is taken to be a pointer to another page, and can be typed by the parser as both a string, and as a pointer to another page.
A value that begins with "" and ends with "" is taken to be a shortened link.
Shortened links are resolved by looking at the machine data on the page indicated by the key: interwiki-index
The page interwiki-index has machine code. All keys represent shortened forms.
For example, "foo: http://blahblahblah/blahblah/$NAME?action=bar" on that page would mean that you could use the shortened form: foo:baz ..and it would link to: http://blahblahblah/blahblah/baz?action=bar Further, there is a "default form" on the page, which is used for situations like baz ...where you are using a link, presumably on the same wiki. This is signified by the key "default" on the interwiki-index page.
mu: suggest the machine code syntax for the Intermap file to follow the standard Intermap file syntax from UseMod wiki.
(which is the same, just ALIAS URL)(usemod users can just copy and paste from their "intermap" file on shell and are machine-readable already)
lk: (? Wouldn't you want to dual-parse it as a string and an integer? If it were a statistic, that is based on the key name, or,...?)
mu: nevermind the statistics part,staying simple
lk: We can link statistics from the AboutThisWiki page, or something like that. :)
Have a page, perhaps programmatically generated: "HitsToday: 365" etc., etc.,.
mu: There is a stats page in every Mediawiki,but i didnt want to get off subject again,sry
lk: For things where there's a huge body of work out there, we can just write adapters. So for instance, write a scraper for Mediawiki statistics pages, and republish them in the machine-code block format.
mu: thats my job ;) i wanted to make a statistics page showing different mediawikis at once anyways. (comparing their stats). Writing a generic "Mediawiki-stats-page" to machinecode script, would be the logical followup
lk: {;D}=
lk: I feel we are close to closer on this. There are two issues in my mind:
1) Can we make it so we don't have to specify the URL to the Intermap? 2) Are we in agreement on a format for the Intermap?
mu: 2) Yes, i think it looks the most simple way possible:
Alias URL Alias URL
<thats just like in usemod,
lk: Hm,... That's pretty different,.
lk: I'd still: <machinecode> aliasA: URL aliasB: URL default: http://.... </machinecode>
lk: (A) we *must* have a default pattern, of some sort, so that you can foo when refering to pages within the immediate wiki, (I feel,) and (B) I'd rather just reuse the machinecode format. It sems easier to me that way. Well, I guess you have to write exporters for the form, change the way you render out the Intermap page. But still: most wiki don't have an entry for themselves in their own intermap. At least, I don't think they do. Is there some standard form for this?
lk: Because, I mean: i believe we want foo -- most of the metadata lookups, I believe, will be from within the same wiki
mu: one could offer ,like you said before, converters for converting UseMod intermap files to machinecode, and creating the same after reading out of mediawiki's mysql table "intermap"
lk: (I know that I can write an automatic generator for MoinMoin. Just read the Intermap file, change it around a bit, and publish that as a MoinMoin action.)
lk: If we agree on this, we can talk about #1- making it so we don't have to publish the URL for the InterMap machinecode page.
mu: i could imagine having a mysql database including all WikiURLs we can find and giving it a button to spit out/create either A) a usemod style intermap file b) a machinecode text bit to copy / paste anywhere
lk: (Problem with centralized list of all wiki prefixes is that it's intrinsicly political. Who has the "futures" moniker: the TaoRiver wiki Futures wiki, or the WikiCities Futures wiki?)
mu: that would not be an approach to have all wikis use the same database. Right, the same problems with centralization arise again.
lk: <nod> Okay.
lk: Okay, so I think we have come to an agrement on thespecific word we use to think to the machine code representing the intermap for our data. There are two magic words we have used:
"default" -- used on the intermap page, to say, "This is the URL prefix to use when the person didn't prefix their link with the name of a wiki" "interwiki-index"
Wait--
I take issue with the word "interwiki" in there-- Again, I believe this will be used for all sorts of mad networking. Not just wiki. So, I would change it to: "url-shortcuts-index:" or something.
mu: You think of dropping the "alias" usage first and only allowing full URLs/URIs to keep it simple?
lk: That was my original idea. I don't know, my heart is cut in two, maybe even three. {;)}=
(1) I want it to be simple. (2) I want it to be easy for people to enter in links, without having to be all geeky about URLs. (3) I work on Local Names, which has the sole purpose in life of exactly doing thes things. (In fact, I'd *really* just rather use Local Names infrastructure for this task.)
mu: If a user wants to use LocalNames in a machine-readable code-block he must put an URL to the index file as the first line,like <machinecode> index: http://
lk: It is sad, but I can only figure out how to use this <machinecode> data from Local Names, and not the other way around. The reason is that the capabilities of the Local Names system are greater, and so they cannot be emulated in the parsers of the machine-code data.
lk: Specificly, Local Names supports namespace hopping. You can say: CommunityWiki:S23:Foo:SomePage, and it can hop hop hop accross all the namespaces.
mu: it is hard to imagine for me how it should work to use any kind of shortcuts/aliases/LocalNames for URLS in interwiki linking, while still avoiding to have any kind of centralized file/place/database to lookup the aliaes / URL. Actually that is like a DNS system. One would need a DNS server to lookup the alias for an URL(prefix). DNS is decntralized ,and hell of complicated ;)
lk: One thing to note, is that just about all meta-data systems do just this. In XML, there's a block at the beginning where you say: "This is the URL, and here's it's shortcut." The same is true of all the RDF formats, not just the XML one. Yes, this is like a DNS system.
lk: see, the thing is: Local Names has exactly that. We have a Local Names server, that takes care of all caching, hoping, even parsing and what not.
lk: We are building a decentralized data network. I call it, "networked data." DNS is networked data. RDF is networked data. XML is not networked data, because it does not have a link to a foreign document as a fundamental type in it's system. (URLs are just strings, and not automatically parsed as URLs.)
mu: learning...i see
lk: You inevitably want caching over large wiki's data stores, and stuff like that,... Because you want to run a for loop which will result in visiting the contents of 30 wiki.
mu: A "DNS" server for wikis. Which is a modified Bind9 that doesnt translate IPs to hostnames, but shortcuts to full URLs
lk: Uh, well,... If you want to know what I believe is the full extent of these ideas,.. I call it "nLSD." Let me find you a link that shows what it looks like.
lk: http://onebigsoup.wiki.taoriver.net/moin.cgi/nLSDgraphs
lk: Look at the XML at the top, lk: the most important node is node #2
lk: I've actually already written a functioning parser and cache for this kind of data. But, I think this is not what we want at this stage for wiki, especially: It's too complicated for users to enter.
mu: That looks like a text-adventure
lk: <laugh> Well, that's just an example. The key thing is that you have native-data type support combined with networked data.
lk: That is, you can link to any node within the file, you can parse it all out as native data, yadda yadda yadda.
lk: If you read that file into an interpreter, you can just transparently walk across files acros the Internet, without even knowing it. You just look up the key "south", or whatever it was, and then the software automatically goes and fetches the next chunk of the data graph from the other URL, and inserts it in place, in the memory data structure.
mu: uuuh, that is hard for me to understand (yet)
lk: Well, let's go back to our machine-code story. It's much simpler, and we've been talking about it for an hour. I believe it will make much more sense in this context.
mu: well, lets implement it on our own WikiNode,
lk: Okay, I'll point CommunityWiki to your own wiki right now.
mu: mattis? you like to add the machine code to our WikiNode to test (just the neighbor: lines)
ma: jepp. d'accordo. (pretending to have understood)
ln: What's the raw form url? How do I get the raw form of a page on S23?
mu: http://is-root.de/wiki/index.php/WikiNode
lk: But, I mean- not in HTML. Do you stick, like, "?action=raw" at the end, or,..?
mu: if you "wget" it, you should have the source, what do you want "stripped off" when refering to "raw"?
lk: I think Mediawiki supports raw pages -- no HTML code, nothing: just the raw edit text.
mu: i see, let me find out mattis, do you see my latest addition to WikiNode? (example)
Put "?raw=1" at the end of our wikinode page--
http://www.emacswiki.org/cw/WikiNode;raw=1
mu: http://is-root.de/wiki/index.php/WikiNode?action=raw
awesome! Okay, submitting.. Done!
lk: Okay, should we take a break, or, what.
I'm ready to go some more here, but, I don't want to tire you out.
mu: you could add your wikinode link to our wikinode and make mattis add them all in machinecode, following the example because ,yes,i admit,i m getting tired. And we have already achieved defining the new standard codeblock.
added; it's there.
But: Let's wait until this is stabilized between ourselves, and within our own wiki, before taking this out to other wiki.
mu: Now,i would like to hide it on mediawiki.mattis, how to comment it out on mediawiki, i dont know yet
lk: Hang on, fixing link.... Need to remember how to make a RawLink on Oddmuse..
mu: hidden ;) (but still in raw mode?)
lk: done, saved {:)}= It's raw now, and works.
lk: Okay. I'm going to write a parser, something so that you can walk the network. I'll probably also expand out our local network on our wiki: Maybe add some information for myself, and Mattis, machinecode encoded.
lk: Meeting ajourned?
lk: And I'm serious about having focused meetings. I'll write up a wiki page describing how I think we should do it, and why.
mu: mattis, you see how we hide the machine code on WikiNode ?
ma. I'm slow, late, sry. Just go ahead,
lk: I'll see you all later. I'm going to shower, get dressed, tend to Kitty, and then I'll be back to write the parser. I suggest we make this PICA 2. Mattis, you'll have to explain PICA to mutante. Hep. {:)}= Take care, all. {:D}=
ma: mega-cool ting, good shower, don't swim put to far. thx.
mu: thanks as well, lets get this Ting closed/saved for today.
ma: saving