Hi Reid,
I'm involved with AcaWiki, so I'll start answers to your questions here. Hopefully others will comment, too.
<Resending from the subscribed address...>
On 23 Mar 2011, at 23:49, Reid Priedhorsky wrote:
On 3/22/11 4:28 PM, Chitu Okoli wrote:
Reid wrote:
There also appear to be various options for Semantic MediaWiki hosting: Wikia, Referata, etc. It would be nice to not have to deal with the sysadmin aspects of the project.
I agree that going with a reliable host would be the way to go. I think that for the nature of our project, choosing a paid Referata plan would probably be better than going for Wikia. I for one could probably easily find grant funding to keep it going.
Sure. If nothing else I'd be happy to chip in personally. I could also ask around for funding here at IBM, but I'm quite pessimistic on that.
Paid plans run from $240 to $960/year, and we could certainly get started for free (http://www.referata.com/wiki/Referata:Features).
I'm not ready to write off AcaWiki, but I have a number of significant concerns. Some of these I've mentioned before. I'd really like someone from that project to comment on these.
- Is the project dead? The mailing list is pretty much empty and the
amount of real editing activity in the past 30 days is pretty low.
Definitely not dead!
- It appears that the project self-hosts - this means that the project
has to do its own sysadmin work,
Neeru & Mike, can you comment on who's doing sysadmin work now?
which appears to have been a problem (e.g., the domain expired earlier this month and no one noticed until the site went down!).
- Is the target audience correct? I think we want to specifically target
our annotated bibliography to researchers, but AcaWiki appears to be targeting laypeople as well as researchers (and IMO it would be very tricky to do both well).
The main interest, from my perspective (others may be able to add their own), is in making research more accessible. Several AcaWiki users are grad students who are writing summaries in order to consolidate their own knowledge or prepare for qualifier exams.
Asking on the
- I don't think the focus on "summaries" is right. I think we need a
structured infobox plus semi-structured text (e.g. sections for contributions, evidence, weaknesses, questions).
I agree! Right now there's some structured information, but that could be readily changed. I'm definitely open to restructuring AcaWiki, so do propose this on the mailing list (acawiki-general@lists.ibiblio.org), and we can discuss further.
One ongoing issue is the best way to handle bibliographic information--which has subtle complexities which we're only partly handling now.
- It doesn't look like a MediaWiki. Since the MW software is so
dominant, that means pretty much everyone who knows about editing wikis knows how to use MW - and not looking like MW means there's no immediate "aha! I can edit this". There's a lot of value in familiarity.
Actually, AcaWiki uses MediaWiki -- specifically Semantic Media Wiki. For full details, see http://acawiki.org/Special:Version
I will post an invitation on the AcaWiki mailing to come here and participate.
One final note on bibliographic software: many of these claim to do automatic import of a reference simply by pointing the software at the publisher's web page for the references. But I have never seen this work correctly; always, the imported data needs significant cleanup, enough that personally I'd rather type it in manually anyway. For example, titles of ACM papers aren't even correctly cased on the official ACM pages (e.g.,http://dx.doi.org/10.1145/1753326.1753615)!
My only experience with "scraping" pages is with Zotero, and it does it beautifully. I assume (but don't know) that the current generation of other bibliography software would also do a good job. Anyway, Zotero has a huge support community, and scrapers for major sources (including Google Scholar for articles and Amazon for books) are kept very well up to date for the most part.
Perhaps I'm just unlucky, then - I've only ever tried it on ACM papers (which it failed to do well, so I stopped).
Zotero used to scrape quite well from the ACM digital library -- now that they've changed their site again the scraper needs to be updated (not hard to do). Last time I tried, Zotero scraped ok from certain ACM pages (item pages) but not from search results: YMMV.
-Jodi
Bi-directional synchronization is hard to get right, particularly when the two sides have different data models. I think we are much better off declaring one or the other to be the master and the rest should remain read-only (i.e. export rather than synchronization).
I like this idea; with SMW as the primary, editable source, a read-only Zotero library imported from the SMW would work well. The problem, though, is that duplicate detection would need to prevent imports from adding existing articles. A complete overwrite would not work, since this would break article IDs for word processor integration. Zotero has been slow on implementing duplicate detection, but they finally have a very impressive solution in alpha (http://www.zotero.org/blog/new-release-multilingual-zotero-with-duplicates-d...).
I don't know anything about how article IDs works in Zotero, but how to build a unique ID for each is an interesting, subtle, and important problem. Others have suggested using opaque IDs such as DOI. I think this is a mistake, because it means that they are utterly meaningless to people when creating citations. For example, consider the following two citations that I might put in my LaTeX code.
\cite{10.1145/1753326.1753615} \cite{Panciera2010Lurking}
The first means nothing to me, but the second is a useful reminder as to the paper I'm citing. That's what CiteULike does, and it's built from first author, year, first meaningful word of title. In the tiny percentage of cases where this is not unique, a disambiguation digit could be added.
I don't know how citation works in Word et al., but I would hope you're not stuck with opaque numeric IDs and/or that Zotero doesn't force you to use integers or something like that.
Reid
Wiki-research-l mailing list Wiki-research-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
Jodi,
Great to have you chip in so quickly.
I am replying only on wiki-research-l to keep the thread from splitting too much.
I'm not ready to write off AcaWiki, but I have a number of significant concerns. Some of these I've mentioned before. I'd really like someone from that project to comment on these.
- Is the project dead? The mailing list is pretty much empty and the
amount of real editing activity in the past 30 days is pretty low.
Definitely not dead!
OK, your quick response is a great start.
However, do you have thoughts on the lack of mailing list activity and very low level of edits? Is there a real community around AcaWiki or just the desire for one?
- It appears that the project self-hosts - this means that the project
has to do its own sysadmin work,
Neeru & Mike, can you comment on who's doing sysadmin work now?
My point here is: I would like to depend on pros for the sysadmin work, rather than volunteers, because there's no need for us to be sysadmins. Let the experts be expert on what they're expert in and all that.
Bottom line: right now I'm not persuaded that the AcaWiki hosting situation is stable. The key example is letting the domain expire and the apparent lack of access to someone who can fix it (see http://lists.ibiblio.org/pipermail/acawiki-general/2011-March/000021.html and http://code.creativecommons.org/issues/msg2778).
The main interest, from my perspective (others may be able to add their own), is in making research more accessible. Several AcaWiki users are grad students who are writing summaries in order to consolidate their own knowledge or prepare for qualifier exams.
OK, that's somewhat different than the goals being proposed in this thread.
I think that's a problem, but perhaps a surmountable one if different communities can have different standards for their papers. We (or I) need to be able to focus on writing "summaries" aimed at other researchers; if someone else wants to come along and add additional summaries for laypeople, that's fine. But (for example) if other people start rewriting our lit review text because it's too technical, I don't think it will work out.
- I don't think the focus on "summaries" is right. I think we need a
structured infobox plus semi-structured text (e.g. sections for contributions, evidence, weaknesses, questions).
I agree! Right now there's some structured information, but that could be readily changed. I'm definitely open to restructuring AcaWiki, so do propose this on the mailing list (acawiki-general@lists.ibiblio.org mailto:acawiki-general@lists.ibiblio.org), and we can discuss further.
Great!
Is there a sandbox where I can experiment (e.g., as in Wikipedia user subpages)?
I don't want a lengthy discussion on a mailing list about what the content of the infobox should be, nor agree across the entire set of disciplines - I'd like to just build one and then iterate with my own community until we agree it's good enough to start (in this case, the people who want to build a wiki research lit review).
One ongoing issue is the best way to handle bibliographic information--which has subtle complexities which we're only partly handling now.
I'd be curious to learn more, though I'll defer that discussion. At a high level, a key concern I have is the perfect becoming the enemy of the good. (For example: dealing with two authors both named John Smith.) I do agree that a big flaw of using (S)MW for this project is the lack of any way to build a structure data model, unless I'm missing big parts of SMW. (RDF triples aren't enough.)
To be clear, what I'm interested in (for now) is not solving these problems but accepting a reasonably good but imperfect platform, which SMW is, and moving forward with the wiki research survey work.
I do have interest in building a better platform, but in the future.
- It doesn't look like a MediaWiki. Since the MW software is so
dominant, that means pretty much everyone who knows about editing wikis knows how to use MW - and not looking like MW means there's no immediate "aha! I can edit this". There's a lot of value in familiarity.
Actually, AcaWiki uses MediaWiki -- specifically Semantic Media Wiki.
Right; what I meant was that while AW does use MW it doesn't *look like* it does, and that's a barrier to entry, which matters. The default skin needs to look more like default MediaWiki.
Reid
Just a few comments adding on to Jodi and Reid's recent posts:
-------- Message original -------- Sujet: Re: [Wiki-research-l] Proposal: build a wiki literature review wiki-style De : Reid Priedhorsky reid@reidster.net Pour : Research into Wikimedia content and communities wiki-research-l@lists.wikimedia.org Copie à : Mike Linksvayer ml@creativecommons.org Date : March-23-11 2:18:34 PM
Neeru& Mike, can you comment on who's doing sysadmin work now?
My point here is: I would like to depend on pros for the sysadmin work, rather than volunteers, because there's no need for us to be sysadmins. Let the experts be expert on what they're expert in and all that.
Bottom line: right now I'm not persuaded that the AcaWiki hosting situation is stable. The key example is letting the domain expire and the apparent lack of access to someone who can fix it (see http://lists.ibiblio.org/pipermail/acawiki-general/2011-March/000021.html and http://code.creativecommons.org/issues/msg2778).
I don't know about the history of AcaWiki stability, but I strongly agree in principle that this project (whether we go with AcaWiki or WikiScholar or whatever) requires a reliable solution where someone is paid for sysadmin work to keep it stable.
The main interest, from my perspective (others may be able to add their own), is in making research more accessible. Several AcaWiki users are grad students who are writing summaries in order to consolidate their own knowledge or prepare for qualifier exams.
OK, that's somewhat different than the goals being proposed in this thread.
I think that's a problem, but perhaps a surmountable one if different communities can have different standards for their papers. We (or I) need to be able to focus on writing "summaries" aimed at other researchers; if someone else wants to come along and add additional summaries for laypeople, that's fine. But (for example) if other people start rewriting our lit review text because it's too technical, I don't think it will work out.
Actually, I feel grad student summaries are an excellent contribution. Although they might not be perfect, grad student seminar assignments would probably be the largest single source of stub articles. Multiply that by every academic field that requires grad students to summarize articles, and I think promoting the wiki as an outlet for grad student work would be the single most effective strategy to make it huge in just one or two years. I, for one, very much see grad students as a major contributing community.
- It doesn't look like a MediaWiki. Since the MW software is so
dominant, that means pretty much everyone who knows about editing wikis knows how to use MW - and not looking like MW means there's no immediate "aha! I can edit this". There's a lot of value in familiarity.
Actually, AcaWiki uses MediaWiki -- specifically Semantic Media Wiki.
Right; what I meant was that while AW does use MW it doesn't *look like* it does, and that's a barrier to entry, which matters. The default skin needs to look more like default MediaWiki.
Actually, I don't agree with Reid on this point. Appearance is very much a subjective issue. Here's my purely subjective opinion: * I find it irritating that hundreds or thousands of MediaWiki instances all look like Wikipedia, as if MediaWiki didn't didn't have any skinning flexibility. (I'm assuming that when Reid says "look like the default MediaWiki", what he effectively means is "look like Wikipedia"; Reid, please correct me if I'm misunderstanding you.) * I like the AcaWiki interface; I wouldn't want to change it to look like Wikipedia.
Less subjectively, I don't think that the appearance is a significant barrier to entry. Saying, "It works just like Wikipedia" should do the job fine to communicate the familiarity of the wiki language.
My only experience with "scraping" pages is with Zotero, and it does it beautifully. I assume (but don't know) that the current generation of other bibliography software would also do a good job. Anyway, Zotero has a huge support community, and scrapers for major sources (including Google Scholar for articles and Amazon for books) are kept very well up to date for the most part.
Perhaps I'm just unlucky, then - I've only ever tried it on ACM papers (which it failed to do well, so I stopped).
Zotero used to scrape quite well from the ACM digital library -- now that they've changed their site again the scraper needs to be updated (not hard to do). Last time I tried, Zotero scraped ok from certain ACM pages (item pages) but not from search results: YMMV. -Jodi
That's probably the issue. We also were stuck for a while when ACM's reformatting of their page structure broke the Zotero translators. For our review, Mohamad on our team had to rewrite the ACM Zotero translator from scratch. I think the problem has been fixed now, though, on the official Zotero translator package. Thus, Reid, you probably just happened to get a bad egg. Unfortunately, whenever publishers reformat their page structures, Zotero translators routinely break.
~ Chitu
On 3/23/11 2:56 PM, Chitu Okoli wrote:
Actually, I feel grad student summaries are an excellent contribution. Although they might not be perfect, grad student seminar assignments would probably be the largest single source of stub articles. Multiply that by every academic field that requires grad students to summarize articles, and I think promoting the wiki as an outlet for grad student work would be the single most effective strategy to make it huge in just one or two years. I, for one, very much see grad students as a major contributing community.
Oh, I definitely agree that grad student contributions are tremendously valuable! (especially having been on until very recently)
My point was this: that writing for a lay audience and writing for fellow researchers (grad students included) are different tasks, and mixing them leads to reduced value for each audience.
I am fine with each paper having a "for laypeople" and "for researchers" section to the summary.
Right; what I meant was that while AW does use MW it doesn't *look like* it does, and that's a barrier to entry, which matters. The default skin needs to look more like default MediaWiki.
Actually, I don't agree with Reid on this point. Appearance is very much a subjective issue. Here's my purely subjective opinion:
- I find it irritating that hundreds or thousands of MediaWiki instances
all look like Wikipedia, as if MediaWiki didn't didn't have any skinning flexibility. (I'm assuming that when Reid says "look like the default MediaWiki", what he effectively means is "look like Wikipedia"; Reid, please correct me if I'm misunderstanding you.)
- I like the AcaWiki interface; I wouldn't want to change it to look
like Wikipedia.
Less subjectively, I don't think that the appearance is a significant barrier to entry. Saying, "It works just like Wikipedia" should do the job fine to communicate the familiarity of the wiki language.
My concern is less with aesthetics than what the interface looks like it does (the "apparent affordances" to use some jargon). As an analogy, I'm sure many of you have encountered Java and Flash applications which have all the same GUI widgets (buttons, scroll bars, etc.) as native OS apps, but they look slightly different. Obviously one can overcome the differences, but unfamiliarity makes the apps harder to use and turns off newbies (or even experienced people who are sick of the "specialness"). (Kai's Power Tools is a classic offender in this regard - where are the controls in this screen shot and how do you use them? http://en.wikipedia.org/wiki/File:Kai%27s_Power_Tools.jpg).
I could certainly be wrong, but this is professional rather than personal opinion, as someone with an HCI education. Sorry for the lack of citations. I do agree that aesthetics is to some degree subjective.
I don't necessarily believe that we need it to be the standard MW look in all respects (though I personally like the consistency), but the wiki controls need to be consistent with other MW installs (most importantly, Wikipedia) so people can see easily that it's a wiki and in particular one they've used before.
Reid
-------- Message original -------- Sujet: Re: [Wiki-research-l] Proposal: build a wiki literature review wiki-style De : Reid Priedhorsky reid@reidster.net Pour : wiki-research-l@lists.wikimedia.org Date : March-24-11 11:53:05 AM
On 3/23/11 2:56 PM, Chitu Okoli wrote: Oh, I definitely agree that grad student contributions are tremendously valuable! (especially having been on until very recently)
My point was this: that writing for a lay audience and writing for fellow researchers (grad students included) are different tasks, and mixing them leads to reduced value for each audience.
I am fine with each paper having a "for laypeople" and "for researchers" section to the summary.
Sorry, Reid; I misunderstood you. I should have said so in my last post, but I certainly do agree with you that it would dilute the usefulness of the articles if they were all written to be accessible to "laypeople"; this kind of simplification would not be as useful to many researchers. I agree that a good solution would be to have the main summary or description written for researchers (who would be the primary audience), but also to include a "For laypeople" section, so that if anyone is inclined to rewrite the main summary for a more general audience, they could do so without affecting the more technical summary.
Right; what I meant was that while AW does use MW it doesn't *look like* it does, and that's a barrier to entry, which matters. The default skin needs to look more like default MediaWiki.
Actually, I don't agree with Reid on this point. Appearance is very much a subjective issue. Here's my purely subjective opinion:
- I find it irritating that hundreds or thousands of MediaWiki instances
all look like Wikipedia, as if MediaWiki didn't didn't have any skinning flexibility. (I'm assuming that when Reid says "look like the default MediaWiki", what he effectively means is "look like Wikipedia"; Reid, please correct me if I'm misunderstanding you.)
- I like the AcaWiki interface; I wouldn't want to change it to look
like Wikipedia.
Less subjectively, I don't think that the appearance is a significant barrier to entry. Saying, "It works just like Wikipedia" should do the job fine to communicate the familiarity of the wiki language.
My concern is less with aesthetics than what the interface looks like it does (the "apparent affordances" to use some jargon). As an analogy, I'm sure many of you have encountered Java and Flash applications which have all the same GUI widgets (buttons, scroll bars, etc.) as native OS apps, but they look slightly different. Obviously one can overcome the differences, but unfamiliarity makes the apps harder to use and turns off newbies (or even experienced people who are sick of the "specialness"). (Kai's Power Tools is a classic offender in this regard
- where are the controls in this screen shot and how do you use them?
Wow, I don't know what he was thinking, but I guess Kai figured that displaying the power of Photoshop art was more important than usability! Maybe I should keep this example for the UI design portion of my systems design class :-)
I could certainly be wrong, but this is professional rather than personal opinion, as someone with an HCI education. Sorry for the lack of citations. I do agree that aesthetics is to some degree subjective.
I don't necessarily believe that we need it to be the standard MW look in all respects (though I personally like the consistency), but the wiki controls need to be consistent with other MW installs (most importantly, Wikipedia) so people can see easily that it's a wiki and in particular one they've used before.
Actually, the controls seem to me to be quite similar to the standard Wikipedia layout. For example, look at http://acawiki.org/Measuring_user_influence_in_Twitter:_The_million_follower.... The page edit controls are on the top of the article, and the navigation bar is on the left, all very similar to Wikipedia. Since these key functional elements are very similar to the default, I assumed that your comments had more to do with the aesthetic elememts. Could you perhaps point out some specific differences in the core MediaWiki functionality elements that you think might confuse new users who are familiar with editing Wikipedia?
Actually, another reason for my comments is that I would assume that the core audience of contributors (academic researchers who are willing to share their research summaries online) would not have trouble trying to learn how to edit, even if AcaWiki used something other than MediaWiki. Other user categories (such as academic researchers who are hesitant to release their contributions as CC-BY) might be less tech-savvy, but I assume that those who are willing to contribute to Internet resources are generally sufficiently Internet-literate enough to learn any simple wiki language. However, like you, I have no citations to back this up; this is just my assumption.
~ Chitu
[I am putting the most interesting stuff at the beginning, but there are some responses in-line below too.]
I spoke with Mako Hill, one of the principals at AcaWiki, last week and am now quite enthusiastic about the system. I believe the flaws can be fixed and we should take advantage of the small but present community which is hungry for new members.
The key problem is hosting, and Mako shares this concern. It turns out that the current hosts (Creative Commons) also would like to transfer hosting somewhere else, as running a MediaWiki is not part of their core mission. So, our interests align.
Thus, I propose that we move AcaWiki hosting to Referata, retaining all existing history and user accounts. If acawiki.referata.com is OK, then it can be done for free; if keeping the acawiki.org domain is important (in this case, the move would be completely transparent to users), then we'll need to find $50/mo; if keeping the existing skin is important (which think it is not - see below), then $80/mo.
AcaWiki folks, what do you think about this? Have I mischaracterized anything about you above?
I would be happy to lead this process (Mako gave me some technical people at CC to talk to) and could start on this in late April. (I have some unavoidable responsibilities in the next few weeks and won't have time until then.)
Once this is done, I could then facilitate the other technical tasks which I offered to do (uploading existing stuff into AcaWiki).
I don't necessarily believe that we need it to be the standard MW look in all respects (though I personally like the consistency), but the wiki controls need to be consistent with other MW installs (most importantly, Wikipedia) so people can see easily that it's a wiki and in particular one they've used before.
Actually, the controls seem to me to be quite similar to the standard Wikipedia layout. For example, look at http://acawiki.org/Measuring_user_influence_in_Twitter:_The_million_follower.... The page edit controls are on the top of the article, and the navigation bar is on the left, all very similar to Wikipedia. Since these key functional elements are very similar to the default, I assumed that your comments had more to do with the aesthetic elememts. Could you perhaps point out some specific differences in the core MediaWiki functionality elements that you think might confuse new users who are familiar with editing Wikipedia?
Hmm, looking again you are right. I'm not sure exactly what happened; perhaps I was confusing AcaWiki with something else.
Anyway, I still don't like the AcaWiki default skin. I could provide a specific critique of the problems I see, but it might be better to simply offer a better one for comparison, which I am happy to do. At a high level, it's a little sloppy, it wastes important vertical space, and standard elements (e.g., search, login) are in nonstandard locations. On the other hand, the default MW skin is very professional looking and gets these things right. It's another aspect of separation of responsibilities - let people who are good at web design design the pages.
Actually, another reason for my comments is that I would assume that the core audience of contributors (academic researchers who are willing to share their research summaries online) would not have trouble trying to learn how to edit, even if AcaWiki used something other than MediaWiki.
That is true; however, many won't. Barriers to entry matter a lot more than one might think, even small ones. The basic theory is, folks who are new to a system don't care much about it and are easy to drive away by making small mistakes. On the other hand, if their initial experience is smooth and pleasant, and enables microcontributions right away, that builds emotional investment in the community and those people are more likely to come back and help build the community and the resource. Researchers in particular are very busy and (I claim) will have less patience than average to hassle with bad systems.
Reid
wiki-research-l@lists.wikimedia.org