> R M Harris
> .. but the time has come, I think, to actively begin a discussion
> within the communities about some of the questions which I've
> encountered, specifically around Commons and images within Commons. ...
> I look forward to the comments of any of you who wish to join the
> discussion.
[Delurking briefly]
Me n'th, endorsing the idea expressed by many others, that
another generic public discussion of these issues will be of dubious
utility. At some point, it's all been said, and as the saying goes,
it's "pounding on a greasy spot on the pavement, where used to lie the
carcass of a dead horse."
The various factions are known. I suppose you have to do this
in order to say you've consulted with the community. But for heaven's
sake, can it at least be done at a level better than yet another rehash?
[Relurking]
--
Seth Finkelstein Consulting Programmer http://sethf.com
Infothought blog - http://sethf.com/infothought/blog/
Interview: http://sethf.com/essays/major/greplaw-interview.php
Den 22. juli. 2010 kl. 01.10 skrev foundation-l-request(a)lists.wikimedia.org
:
> Hello
>
> I use pbworks, basic plan (free)
> https://plans.pbworks.com/
>
> Indeed, that is not mediawiki, but I find that specific wiki quite
> confortable to work with and the hosting service is good (not lagging
> horribly as other wiki farms are something doing).
>
> I have been testing it for roughly two months and feel happy about it.
> Currently considering going for the for-pay plan to use it for my
> business to communicate with my clients.
>
> The basic plan allow only one space, but this space can be closed.
> So it
> should fit your needs.
>
> Alternatively, you may set up your own mediawiki (I also have one),
> but
> this require
> * hosting service
> * domain name
> * install and updates
>
> To be fair, unless you are a total geek and mediawiki fan, I would
> recommand the no-hassle pbworks solution.
>
> Ant
I have tried this too for a paper written some time ago.
http://ninano.pbworks.com/Wikipedia-and-the-Museum
Its, nice.
Nina
nina.wikipedia(a)gmail.com
MY NAME IS PHILLIP CAREY, PHILLIP.A.CAREY(a)IRS.GOV , AND I AM A HARD DILIGENT
WORKER I AM ALSO HANDICAPPED I HAVE WORED FOR FEDERAL
GOVERNMENT FOR ABOUT25 YEARS SEEING THE NEED FOR HUMAN RESOURCES.
AND I AM MORE THAN WILLING TO ACEPT RESPONSABLI T Y FOR SUCH SERVICES.
iF ANY REFRENCES ARE REQUIRED JUST ASK ANYONE WHO KNOWS ME.
I HAVE COLLEGE DEGREE IN COMPUTER USE AND WORKED IN FEDERAL COMPUTER ROOM
FOR ALMOST 19 TEARS.
PHILLIP.A.CAREY(a)IRS.GOV
phillip a. carey
P.A.C.
[[User:Mauro742]] has produced some statistics:
http://meta.wikimedia.org/wiki/Usage_of_edit_summary_on_Wikipedia
There are great differences among Wikipedias.
Apparently, sk.wiki and pl.wiki are the only Wikipedias where standard
edit summaries buttons are used, and where edit summary usage is about 90%.
Wha to do you think? Are those buttons useful, or maybe they make edit
summaries more similar and pointless? Do they increase usability? Should
we introduce them elsewhere?
Nemo
Yeah, Casey is correct --- basically, what I was saying is that there are other avenues than public mailing lists, and that there are people ready and willing to pay attention if something is wrong.
Thanks,
Sue
------Original Message------
From: Casey Brown
Sender: Casey Brown
To: foundation-l(a)lists.wikimedia.org
Cc: Sue Gardner GMail
Subject: Re: [Foundation-l] Money, politics and corruption
Sent: 14 Jul 2010 18:20
On Wed, Jul 14, 2010 at 6:00 PM, Federico Leva (Nemo)
<nemowiki(a)gmail.com> wrote:
> Anyone? Looks like it applies only to employees.
> http://wikimediafoundation.org/wiki/Whistleblower_Policy
> "entity with whom Wikimedia Foundation Inc has a business relationship"
> includes chapters?
>
I'm sure she was mentioning it in spirit -- basically "you can see
we're interested in whistleblowers and have this protection/policy
already in place for our employees; anyone else should feel free to
report any issues they think exist as well".
--
Casey Brown
Cbrown1023
Hello,
I'm writing this as the follow-up to Jimmy Wales' Wikimania keynote
about small Wikipedias, or, as some people correctly say, Wikipedias
in underprivileged languages. (It's strange to use the word "small"
anywhere near Bengali, for example.)
Is there some recorded body of knowledge about the existing attempts
to engage small language communities? The only thing that i know is
the parts with Ndesanjo Macha in "The Truth According To Wikipedia".
They are very inspiring, but very small.
Were there any people that, for example, worked with schools that
function in underprivileged languages and tried to teach students
there to write Wikipedia articles in their language? If there were,
can i read, hear or watch their experiences anywhere?
--
אָמִיר אֱלִישָׁע אַהֲרוֹנִי
Amir Elisha Aharoni
http://aharoni.wordpress.com
"We're living in pieces,
I want to live in peace." - T. Moore
On Tue, Jul 20, 2010 at 11:56 AM, Jodi Schneider <jodi.schneider(a)deri.org>wrote:
> Hi Brian,
>
> On 20 Jul 2010, at 18:02, Brian J Mingus wrote:
>
> On Mon, Jul 19, 2010 at 4:06 PM, Finn Aarup Nielsen <fn(a)imm.dtu.dk> wrote:
>
>>
>>
>> Hi Brian and others,
>>
>> I also think that it would be interesting with some bibliographic support,
>> for two-way citation tracking and commenting on articles (for example), but
>> I furthermore find that particular in science article we often find data
>> that is worth structuring and put in a database or a structured wiki, so
>> that we can extract the data for meta-analysis and specialized information
>> retrieval. That is what I also do in the Brede Wiki. I use the templates to
>> store such data. So if such a system as yours is implemented we should not
>> just think of it as a bibliographic database but in more broader terms: A
>> data wiki.
>
>
> Although the technology required to make a WikiCite happen will be
> applicable to a more generalized wiki for storing data I think that is too
> broad for the current proposal. A WMF analogue to Google Base is an entirely
> new beast that has its own requirements. I certainly think it's an
> interesting and worthwhile idea, but I don't feel that we are there yet.
>
> As the 'key' (the wiki page title) I use the (lowercase) title of the
>> article. That might be more reader friendly - but usually longer. I think
>> that KangHsuKrajbichEtAl09 is too camel-cased. Neither the title nor author
>> list + year will be unique, so we need some predictable disambig.
>
>
> I noticed that AcaWiki is using the title, but I am personally not a fan of
> it. The motivation for using a key comes from BibTeX. When you cite an entry
> in a publication in LaTeX, you type \cite{key}. Also, I think most
> bibliographic formats support such a key. The idea is that there is a
> universal token that you can type into Google that will lead you to the
> right item. The predictable disambig is in the format I sent out (which
> likely needs modification for other kinds of sources). The format is
> Author1Author2Author3EtAlYYb. Here is a real world example from a pair of
> very prolific scientists, Deco & Rolls, who published at least three papers
> together in 2005. In our lab we have really come to love these keys - they
> are very memorable tokens that you can verbally pass on to other scientists
> in the midst of a discussion. Eventually, if they enter the key you have
> given them into Google, they will get the right entry at "WikiCite".
>
>
> DecoRolls05 - Synaptic and spiking dynamics underlying reward reversal in
> the orbitofrontal cortex.
> DecoRolls05b - Sequential memory: a putative neural and synaptic dynamical
> mechanism.
> DecoRolls05c - Attention, short-term memory, and action selection: a
> unifying theory.
>
>
> Citation keys of this sort work, but they have to be decided on by some
> external system. Who decides which paper is -, b, and c? Publication order
> would be one way to do it -- but that's complicated, especially with online
> first publication, or overlapping conferences.
>
> I think whether they're memorable tokens might vary by person... Sure, the
> author and year will be identifiable, even memorable. But the a, b, c?
>
> If you want to support more than recent works, I'd urge YYYY instead of YY.
> Then we only have an issue for pre-0 stuff. :)
>
> Also consider differentiating authors from title and year, perhaps with
> slashes.
> author1-author2-author3-etal/YYYY/b
> I'm not convinced that -'s are better than capital letters (author last
> names can have both)...
>
The key seems to be a very important point, so it's important that we get it
right. My thinking is guided by several constraints. First, I strongly
dislike the numeric keys used at sites such as CiteULike and most database
sites (such as 7523225). To the greatest degree possible I believe the key
should actually convey what is behind the link. On the other hand, the key
should not be too long. Numeric keys maximize the shortness while telling
you nothing , whereas titles as keys are very long and don't give you some
of the most important information - the authors and the year it was
published. The key format I have suggested does seem to have a flaw, being
that it easily becomes ambiguous and you must resort to a token that is not
easily memorable. Then again, even though many authors and sets of authors
will publish multiple items in a year, the vast majority of works have a
unique set of authors for a given year.
I like your suggestion that the abc disambiguator be chosen based on the
first date of publication, and I also like the prospect of using slashes
since they can't be contained in names. Using the full year is a good idea
too. We can combine these to come up with a key that, in principle, is
guaranteed to be unique. This key would contain:
1) The first three author names separated by slashes
2) If there are more than three authors, an EtAl
3) Some or all of the date. For instance, if there is only one source by
this set of authors that year, we can just use YYYY. However, once another
source by those set of authors is added, the key should change to MMDDYYYY
or similar. If there are multiple publications on the same day, we can
resort to abc. Redirects and disambiguation pages can be set up when a key
changes.
Since the slashes are somewhat cumbersome, perhaps we can not make them
mandatory, but similarly use them only when they are necessary in order to
"escape" a name. In the case that one of the authors does not have a slash
in their name - the dominant case - we can stick to the easily legible and
niecly compact CamelCase format.
Example keys generated by this algorithm:
KangHsuKrajbichEtAl2009
Author1Author2/Author-Three/2009
Author1Author2AuthorThree10032009
Author1Author2AuthorThree12312009
>
> I have one field to each author so that I can automatically link authors.
>
>
> This is accomplished via Semantic Forms, using the arraymap parser
> function. You just provide a comma-separated list of authors, and they each
> get semantic property definitions and deep linking to all papers published
> by that author.
>
>
> Sure -- unless authors have the same name, or use different forms of the
> name.
>
> One of my coauthors goes by John G. Breslin for disambiguration since his
> name is common -- but on the institute website he's credited as John
> Breslin, since that's the only name the system recognizes.
>
> In other words, some authority control will be needed. Libraries have a
> long history with this. Groups of booklovers do it, too. For instance,
> here's the LibraryThing page for John Smith:
> http://www.librarything.com/author/smithjohn
> Notice that you can split and join authors -- LibraryThing's way of giving
> users the ability to join and separate.
> Or see
> http://www.librarything.com/author/carrolllewis
> Sometimes there are difficult questions -- such as "Is Lewis Carroll the
> same as Charles Dodgson?" - which depends on what you mean by "same".
>
> For the scope of the potential problem, look at highly published authors --
> for instance the "alternative names" list for Dante:
> http://www.worldcat.org/identities/lccn-n78-95495
>
>
LibraryThing is a great example of how to do disambiguation. We can only
hope that we can likewise someday have a user community as pedantic and
dedicated as theirs ;-) A big part of their success is in providing their
users with straightforward tools for doing the disambig work.
>
> I do not include abstracts in my CC-by-sa'ed wiki, since I am not sure how
>> publishers regard the copyright for abstracts. Neither I am sure about the
>> forward cites. Most commerical publishers hide the cites for unpaid viewing.
>> Including cites in CC-by-sa material on a large-scale may infringe
>> publishers' copyright. Perhaps it is possible to negotiate with some
>> publishers. We need some talk with 'closed access' publishers before we add
>> a such data.
>
>
> Yes, I have added many nice features to WikiPapers that can unfortunately
> not make it into the proposed WMF project. Some can, some can't. For
> example, adding papers to the wiki is via a one click bookmarklet. First,
> you highlight the title of a paper anywhere on the web, be it a webpage,
> e-mail, or journal site. Then, you click your "Add to wiki" bookmarklet. On
> my webserver I am running the citation scraping software from Connotea,
> CiteULike, and Zotero. I also have a Google Scholar scraper and PubMed
> importer. You can choose to use one of those sources, or you can choose to
> merge all of the metadata together. It's automatically added to the wiki for
> you. Additionally, I have written a bash script that is very adept at
> getting the pdfs from journals, so it automatically tries to download the
> pdf and upload it to the wiki for you. I have also implemented the ability
> to compute the articles that an article cites, and vice versa. With respect
> to abstracts these scrapers aren't that great. Abstracts usually come from
> PubMed, whose database you can license, but you cannot change their metadata
> IIRC.
>
> Ultimately, I think the community will have to take a very careful look at
> what data can be added to the wiki and design policies accordingly. On
> Wikipedia I believe copyright enforcement has largely been up to the
> community, and it takes a long time to converge on appropriate policies.
> Needless to say, much of the technologies I described in the last paragraph
> would not be found legal on a public wiki.
>
> I am not sure what 'owner' is in your format. Surely you cant have owners
>> in Wikimedia/MediaWiki wiki? And 'dateadded' would already be recorded in
>> the revision history.
>
>
> The 'owner' field is a misnomer, but in lieu of mysql support it lets you
> know which individuals have that entry in their personal bibliographies.
> dateadded is needed due to what at least used to be a bug in Semantic
> MediaWiki.
>
> We probably need to check on the final format of the bibliographic template
>> to make sure it is easy translatable to the most common bibliographic
>> formats: bibtex, refman, Z3988 microformat, pubmed, etc.
>
>
> I have written extensive amounts of Python interchange code between wiki
> template syntax and BibTeX. I chose BibTeX because it is rather standard,
> our lab uses it, and it is very similar to template syntax. Also, I use
> Bibutils to convert from BibTeX to most popular formats, and vice versa for
> mass import of bibliographies:
> http://www.scripps.edu/~cdputnam/software/bibutils/
>
>
> BibTeX is good for backwards compatibility, but I'd urge a richer data
> format -- probably based on bibo RDF:
> http://bibliontology.com/
> It's already widely used: http://bibliontology.com/projects
>
>
It was probably a mistake for me to describe WikiPapers as designed around
BibTeX. In fact, it's designed around mediawiki templates. From templates as
your start, you can support any other format for both import and export.
>
> As I understand there are issue with Semantic MediaWiki with respect to
>> performance and security that needs to be resolved before a large scale
>> deployment within Wikimedia Foundation projects. I heard that Markus
>> Krötzsch is going to Oxford to work on core SMW, so there might come some
>> changes to SMW in the future. Code audit of SMW lacks.
>
>
> As I was writing a custom Lucene search engine for WikiPapers I realized
> that it is a perfect replacement for Semantic MediaWiki. Lucene has fields,
> it supports boolean operators and you can format its output. All that is
> needed is to write the Lucene backend (perhaps just modifying MWLucene) and
> write a parser function that supports using templates for formatting of the
> output of queries. Lucene is extremely fast and can scale to whatever we can
> imagine doing. That's my proposed plan.
>
> It not 'necessarily necessary' to make a new Wikimedia project. There has
>> been a suggestion (in the meta or strategy wiki) just to use a namespace in
>> Wikipedia. You could then have a page called
>> http://en.wikipedia.org/wiki/Bib:The_wick_in_the_candle_of_learning
>
>
> I believe it is necessary. First, the idea is for any mediawiki anywhere
> (and any software with appropriate extensions) to be able to cite the same
> source. Secondly, the project would be multilingual.
>
>
> I think somebody's mentioned OpenLibrary on this thread. In case not:
> http://openlibrary.org/
> Its scope is limited to books, but their interests are similar.
>
> -Jodi
>
> <http://openlibrary.org/>
>
>
> Cheers,
>
> Brian Mingus
> Graduate Student
> Computational Cognitive Neuroscience Lab
> University of Colorado at Boulder
>
> _______________________________________________
> Wiki-research-l mailing list
> Wiki-research-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
>
>
>
> _______________________________________________
> Wiki-research-l mailing list
> Wiki-research-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
>
>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello all!
Next Thursday's office hours will feature Véronique Kessler, the
Foundation's Chief Financial Officer. If you don't know
Naoko, you can get to know her at
<http://wikimediafoundation.org/wiki/V%C3%A9ronique_Kessler>.
Office hours on Thursday are from 2100 to 2200 UTC (3:00 PM - 4:00 PM PDT).
If you do not have an IRC client, there are two ways you can come chat
using a web browser: First is using the Wikizine chat gateway at
<http://chatwikizine.memebot.com/cgi-bin/cgiirc/irc.cgi>. Type a
nickname, select irc.freenode.net from the top menu and
#wikimedia-office from the following menu, then login to join.
Also, you can access Freenode by going to http://webchat.freenode.net/,
typing in the nickname of your choice and choosing wikimedia-office as
the channel. You may be prompted to click through a security warning.
It should be all right.
Please feel free to forward (and translate!) this email to any other
relevant email lists you happen to be on. Also note, this is
Veronique's first foray into IRC, so lets show her how welcoming we can
be! :-)
- --
Cary Bass
Volunteer Coordinator, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAksDQcwACgkQyQg4JSymDYl+wACcCsTgIUtThC4agEUwC9533olx
61cAn1titMJqMmNt4GESgoQ9U5sQMFM7
=1DvA
-----END PGP SIGNATURE-----
On Tue, Jul 20, 2010 at 5:10 AM, Daniel Kinzler <daniel(a)brightbyte.de>wrote:
> Hi all
>
> A central place for managing Bibliographic data for use with Citations is
> something that has been discussed by the German community for a long time.
> To
> me, it consists of two parts: a project for managing the structured data,
> and a
> machanism for uzsing that data on the wikis.
>
> I have been working on the latter recently, and there's a working
> prototype: on
> <http://prototype.wikimedia.org/wmde-sandbox-1/Wikipedia:DataTransclusion>
> you
> can see how data records can be included from external sources. A demo for
> the
> actual on-wiki use can be found at
> <http://prototype.wikimedia.org/wmde-sandbox-1/Ameisenigel#Literatur>,
> where
> {{ISBN|0868400467}} is used to show the bibliographic info for that book.
> (side
> note: the prototype wikis are slow. sorry about that).
>
> Fetching and showing the data is done using
> <http://www.mediawiki.org/wiki/Extension:DataTransclusion>. Care has been
> taken
> to make this secure and scalable.
>
> For a first demo, I'm using teh ISBN as the key, but any kind of key could
> be
> used to reference resources other than books.
>
> For demoing managing the data by ourselves, I have set up ab SMW instance.
> An
> example bib record is at
> <http://prototype.wikimedia.org/wmde-bib/ISBN:0451526538>, it's used
> across
> wikis at
> <http://prototype.wikimedia.org/wmde-sandbox-1/Wikipedia:DataTransclusion>.
> Note
> that changes will show delayed, as the data is cached for a while.
>
>
> When discussing these things, please keep in mind that there are two
> components:
> fetching and displaying external data records, and managing structured data
> in a
> wiki style. The former is much simpler than the latter. I think we should
> really
> aim at getting both, but we can start off with transclusing external data
> much
> faster, if we allow no-so-wiki data sources. For ISBN-based queries, we
> could
> simply fetch information from http://openlibrary.org - or the open
> knowledge
> foundation's http://bibliographica.org, once it's working.
>
> In the context of bibdex, I recommend to also have a look at
> http://bibsonomy.org - it's a university research project, open source,
> and is
> quite similar to bibdex (and to what citeulike used to be).
>
> As to managing structured data ourselves: I have talked a lot with Erik
> Möller
> and Markus Krötzsch about this, and I'm in touch with the people wo make
> DBpedia
> and OntoWiki. Everyone wants this. But it's not simple at all to get it
> right
> (efficient versioning of multilingual data in a document oriented database,
> anyone? want inference? reasoning, even? yay...). So the plan is currently
> to
> hatch a concrete plan for this. And I imagine that bibliographical and
> biographical info will be among the first used cases.
>
>
Hi Daniel,
Have you considered that Lucene is the perfect backend for this kind of
project? What kinds of faults do you see with it? At least in my mind, we
can mold it to our needs here. It has the core capabilities found in
Semantic MediaWiki, and it is fast and scalable.
I say this as a serious user of Semantic MediaWiki. I have seen that it
can't scale well without an alternate backend, and I wonder what kind of
monumental effort will be required to make it scale to tens or hundreds of
millions of documents, each of which containing 20-50 properties. Lucene can
already do this, SMW, not so much ;-)
Brian
> cheers,
> daniel
>
>
> _______________________________________________
> Wiki-research-l mailing list
> Wiki-research-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wiki-research-l
>
On Mon, Jul 19, 2010 at 4:06 PM, Finn Aarup Nielsen <fn(a)imm.dtu.dk> wrote:
>
>
> Hi Brian and others,
>
> I also think that it would be interesting with some bibliographic support,
> for two-way citation tracking and commenting on articles (for example), but
> I furthermore find that particular in science article we often find data
> that is worth structuring and put in a database or a structured wiki, so
> that we can extract the data for meta-analysis and specialized information
> retrieval. That is what I also do in the Brede Wiki. I use the templates to
> store such data. So if such a system as yours is implemented we should not
> just think of it as a bibliographic database but in more broader terms: A
> data wiki.
Although the technology required to make a WikiCite happen will be
applicable to a more generalized wiki for storing data I think that is too
broad for the current proposal. A WMF analogue to Google Base is an entirely
new beast that has its own requirements. I certainly think it's an
interesting and worthwhile idea, but I don't feel that we are there yet.
As the 'key' (the wiki page title) I use the (lowercase) title of the
> article. That might be more reader friendly - but usually longer. I think
> that KangHsuKrajbichEtAl09 is too camel-cased. Neither the title nor author
> list + year will be unique, so we need some predictable disambig.
I noticed that AcaWiki is using the title, but I am personally not a fan of
it. The motivation for using a key comes from BibTeX. When you cite an entry
in a publication in LaTeX, you type \cite{key}. Also, I think most
bibliographic formats support such a key. The idea is that there is a
universal token that you can type into Google that will lead you to the
right item. The predictable disambig is in the format I sent out (which
likely needs modification for other kinds of sources). The format is
Author1Author2Author3EtAlYYb. Here is a real world example from a pair of
very prolific scientists, Deco & Rolls, who published at least three papers
together in 2005. In our lab we have really come to love these keys - they
are very memorable tokens that you can verbally pass on to other scientists
in the midst of a discussion. Eventually, if they enter the key you have
given them into Google, they will get the right entry at "WikiCite".
DecoRolls05 - Synaptic and spiking dynamics underlying reward reversal in
the orbitofrontal cortex.
DecoRolls05b - Sequential memory: a putative neural and synaptic dynamical
mechanism.
DecoRolls05c - Attention, short-term memory, and action selection: a
unifying theory.
I have one field to each author so that I can automatically link authors.
This is accomplished via Semantic Forms, using the arraymap parser function.
You just provide a comma-separated list of authors, and they each get
semantic property definitions and deep linking to all papers published by
that author.
I do not include abstracts in my CC-by-sa'ed wiki, since I am not sure how
> publishers regard the copyright for abstracts. Neither I am sure about the
> forward cites. Most commerical publishers hide the cites for unpaid viewing.
> Including cites in CC-by-sa material on a large-scale may infringe
> publishers' copyright. Perhaps it is possible to negotiate with some
> publishers. We need some talk with 'closed access' publishers before we add
> a such data.
Yes, I have added many nice features to WikiPapers that can unfortunately
not make it into the proposed WMF project. Some can, some can't. For
example, adding papers to the wiki is via a one click bookmarklet. First,
you highlight the title of a paper anywhere on the web, be it a webpage,
e-mail, or journal site. Then, you click your "Add to wiki" bookmarklet. On
my webserver I am running the citation scraping software from Connotea,
CiteULike, and Zotero. I also have a Google Scholar scraper and PubMed
importer. You can choose to use one of those sources, or you can choose to
merge all of the metadata together. It's automatically added to the wiki for
you. Additionally, I have written a bash script that is very adept at
getting the pdfs from journals, so it automatically tries to download the
pdf and upload it to the wiki for you. I have also implemented the ability
to compute the articles that an article cites, and vice versa. With respect
to abstracts these scrapers aren't that great. Abstracts usually come from
PubMed, whose database you can license, but you cannot change their metadata
IIRC.
Ultimately, I think the community will have to take a very careful look at
what data can be added to the wiki and design policies accordingly. On
Wikipedia I believe copyright enforcement has largely been up to the
community, and it takes a long time to converge on appropriate policies.
Needless to say, much of the technologies I described in the last paragraph
would not be found legal on a public wiki.
I am not sure what 'owner' is in your format. Surely you cant have owners in
> Wikimedia/MediaWiki wiki? And 'dateadded' would already be recorded in the
> revision history.
The 'owner' field is a misnomer, but in lieu of mysql support it lets you
know which individuals have that entry in their personal bibliographies.
dateadded is needed due to what at least used to be a bug in Semantic
MediaWiki.
We probably need to check on the final format of the bibliographic template
> to make sure it is easy translatable to the most common bibliographic
> formats: bibtex, refman, Z3988 microformat, pubmed, etc.
I have written extensive amounts of Python interchange code between wiki
template syntax and BibTeX. I chose BibTeX because it is rather standard,
our lab uses it, and it is very similar to template syntax. Also, I use
Bibutils to convert from BibTeX to most popular formats, and vice versa for
mass import of bibliographies:
http://www.scripps.edu/~cdputnam/software/bibutils/
As I understand there are issue with Semantic MediaWiki with respect to
> performance and security that needs to be resolved before a large scale
> deployment within Wikimedia Foundation projects. I heard that Markus
> Krötzsch is going to Oxford to work on core SMW, so there might come some
> changes to SMW in the future. Code audit of SMW lacks.
As I was writing a custom Lucene search engine for WikiPapers I realized
that it is a perfect replacement for Semantic MediaWiki. Lucene has fields,
it supports boolean operators and you can format its output. All that is
needed is to write the Lucene backend (perhaps just modifying MWLucene) and
write a parser function that supports using templates for formatting of the
output of queries. Lucene is extremely fast and can scale to whatever we can
imagine doing. That's my proposed plan.
It not 'necessarily necessary' to make a new Wikimedia project. There has
> been a suggestion (in the meta or strategy wiki) just to use a namespace in
> Wikipedia. You could then have a page called
> http://en.wikipedia.org/wiki/Bib:The_wick_in_the_candle_of_learning
I believe it is necessary. First, the idea is for any mediawiki anywhere
(and any software with appropriate extensions) to be able to cite the same
source. Secondly, the project would be multilingual.
Cheers,
Brian Mingus
Graduate Student
Computational Cognitive Neuroscience Lab
University of Colorado at Boulder