Sponsored link
Sponsored link
If you're not sold on the idea of making your service work with CiteULike then think of it this way: You'll get endless advertising for your site - for free!
CiteULike is effectively just a large collection of links to articles on external publishers' sites. If your business model involves selling content, and if you make more money if more people read your articles, then it's almost certainly something you ought to be interested in. If your site works with CiteULike then our users can bookmark articles and share them with other specialists in their fields. Marketing people enthuse about viral marketing. You can have it - for free.
What's even better, is that this doesn't compete in any way with what we're doing. We're interested in building communities, and trying to spot patterns in what people are reading. If we can provide a useful service to academics by pointing them towards important papers in their fields then we're happy. We're also as happy to work with conventional publishers as we are to work with open access publishers. We've got no open access evangelism agenda.
Although we're in no immediate hurry to make money out of CiteULike, our revenue stream may eventually come from targeted advertising on the site ("Good" adverts, as Google calls them, like an advert for something you actually need - like a job in your field), and by licensing the server software to research companies who're interested in collaboration amongst their employees, but don't want the details of what they're reading to go into the public domain.
The bottom line is that we're interested in linking to your content as it makes our site more useful, and you're probably interested in having your readers implicitly recommend your articles to other people. Simple. And there's not even a cryptic symbiotic buzzword in there.
If you've experimented with CiteULike as a user, you'll see that you can install a javascript bookmarklet in you bookmarks bar, surf to a "supported" site, find an article, and click the "Post to CiteULike" bookmarklet.
What happens behind the scenes is this:
As well as storing articles that our users have actually chosen to post, we're also interested in maintaining a collection of articles which they might want to read. Our users can then search within CiteULike for these, and post them to their libraries if they find them interesting.
We do this by subscribing to RSS feeds from publishers. There's a standard which allows you to embed all the useful metadata (enough to for a proper bibliographic citation) in the feed, and that's what we need.
If you have multiple RSS feeds (one for each journal, say), then we can parse an OPML file which contains a list of where they are.
We already have feeds from Nature and feeds from IngentaConnect. These let us keep the latest issue of all these journals "on the shelf", as it were, such that our users can be informed of all the new articles when they're published.
There are a few options. Please get in touch and we can have a chat about them. However, you'll probably want to do at least some of these things:
If you're a major publisher, then we have developer resources to write a plugin for you. If you're not such a major publisher, then you might be on your own to write the plugin, or you'll have to really persuade us to do it! We've got a finite amount of time, and there are plenty of sites we need to build support for. Either way, there are some things you can do to make this easy:
http://www.bigpublisher.com/view_article?id=1234 is much nicer than, say, http://www.bigpublisher.com/search?query=something_the_user_searched_for&page=24
&item=7&random_important_magic_number=12. We're interested in storing the raw ingredients to be able to construct a stable URL for your article. Anything you can do to make this easier will help us.You can do this if you want. You'll need to write it in a language called "Tcl". Maybe things will change in later versions of the plugin handler, but that's the requirement for the moment.
The choice of language might sound slightly annoying, but it's designed to be one with a trivial syntax which a good programmer can pick up in an afternoon. It's something like Perl, although a little bit less insane in terms of language design.
There's some provisional documentation, and that should give you an example of how long it might take. If you do want to go down this route, please let us know and we can provide help.
If you can provide an RSS feed with PRISM metadata in it then that would be extremely helpful. We'll poll the feed for new articles and we'll alert our users when they're published. If you've got lots of RSS feeds then create an OPML file and send us the link. If you've really got loads of them, then remember that we'll need to poll each and every one regularly, so think about aggregating them together into a "new articles" feed if you're worried about us creating too much load on your server.
Creating an RSS feed is probably a good thing to do anyway. Librarians seem to be increasingly interested in this technology, so it might be of general benefit to your site.
If you can, provide abstracts in the feed. We'll display them on CiteULike and you might pique the interest of some of our readers if they can see them.
We take the view that it is reasonable to display citation details and abstracts on our website where they are publicly available anyway (in bibliographies in the literature, for example). If you have any specific requirements then let us know. Maybe you require us to display copyright information if the copyright to, say, your abstracts in not held by you?
Although we can and do add support for certain publishers without talking to them, it's always good to have someone we can talk to at your end if we encounter problems. Actually, because CiteULike parses pages on a regular basis, we sometimes discover bugs in publishers' sites before they do. As a heavy consumer of RSS feeds, we can sometimes spot problems that you might not. Some publishers find it useful to hear from us anyway as we can generally supply you with proper technical bug reports as opposed to some of the ones which come in from the general public.
We're a small organization, and the site's growing fast. We've got time to answer your questions and - amazingly - we actually use human beings rather than computer programs designed solely to "Thank you for your email and interest in CiteULike." If there's anything you need to know, then please email us.