Copac Developments

A couple of weeks ago, I attended JISC’s Modelling the Library Domain Workshop. I was asked to facilitate some sessions at the workshop, which was an interesting but slightly (let’s say) ‘hectic’ experience. Despite this, I found the day very positive. We were dealing with potentially contentious issues, but I noted real consensus around some key points. The ‘death of the OPAC’ was declared and no blood was shed as a result. Instead I largely heard murmured assent. As a community, we might have finally faced a critical juncture, and there were certainly lessons to be learned in terms of considering the future of services such as Copac, which as a web search service, in the Library Domain Model would count as national JISC service ‘Channel.’

In the morning, we were asked to interrogate what has been characterised as the three ‘realms’ of the Library Domain: Corporation, Channels, and Clients. (For more explanation of this model, see the TILE project report on the Library Domain Model). My groups were responsible for picking apart the ‘Channel’ realm definition:

The Channel – a means of delivering knowledge assets to Clients, not necessarily restricted to the holdings or the client base of any particular Corporation, Channels within this model range from local OPACs to national JISC services and ‘webscale’ services such as Amazon and Google Scholar. Operators of channel services will typically require corporate processes (e.g. a library managing its collection, an online book store managing its stock). However, there may be an increasing tendency towards separation, channels relying on the corporate services of others and vice versa (e.g. a library exposing its records to channels such as Google or Liblime, a bookshop outsourcing some of its channel services to the Amazon marketplace).

In subsequent discussion, we came up with the following key points:

• This definition of ‘channel’ was too library-centric. We need to working on ‘decentring’ our perspective in this regard.

• We will see an increasing uncoupling of channels from content. We won’t be pointing users to content/data but rather data/content will be pushed to users via a plethora of alternative channels

• Users will increasingly expect this type of content delivery. Some of these channels we can predict (VLEs, Google, etc) and others we cannot. We need to learn to live with that uncertainty (for now, at least).

• There will be an increasing number of ‘mashed’ channels – a recombining data from different channels into new bespoke/2.0 interfaces.

• The lines between the realms are already blurring, with users becoming corporations and channels….etc., etc.

• We need more fundamental rethinking of the OPAC as the primary delivery channel for library data. It is simply one channel, serving specific use-cases and business process within the library domain.

• Control. This was a big one. In this environment libraries increasingly devolve control of the channels via which their ‘clients’ use to access the data. What are the risks and opportunities to be explored around this decreasing level of control? What related business cases already exist, and what new business models need to evolve?

• How are our current ‘traditional’ channels actually being used? How many times are librarians re-inventing the wheel when it comes to creating the channels of e-resource or subject specialist resource pages? We need to understand this in broad scale.

• Do we understand the ways in which the channels libraries currently control and create might add value in expected and unexpected ways? There was a general sense that we know very little in this regard.

There’s a lot more to say about the day’s proceedings, but the above points give a pretty good glimpse into the general tenor of the day. I’m now interested to see what use JISC intends to make of these outputs. The ‘what next?’ question now hangs rather heavily.

We’ve been hinting a while now about significant changes being imminent for Copac, and I am now pleased to announce that we’ve had official word that we have secured JISC funding to overhaul the Copac service over the next year.

The major aim for this work is to improve the Copac user experience.  In the short term this will mean improving the quality of the search results.  More broadly, this will mean providing more options for personalising and reusing Copac records.

We’re going to be undertaking the work in two phase.  We’re calling Phase 1 the  ‘iCue Project’ (stands for ‘Improving the Copac User Experience’).  This work will be focused on  investigating and proposing pragmatic solutions that improve the Copac infrastructure and end-user experience, and we’re going to be partnering with Mark Van Harmelen of Personal Learning Environments Ltd (PLE) in this work (Mark is also involved in the JISC TILE project, so we believe there’s a lot of fruitful overlap there, especially around leveraging the potential of circulation data a la Huddersfield).  The second phase is really about doing the work — re-engineering Copac in line with the specifications defined in the iCue Project.

We see this work tackling three key areas for Copac:

(i)    Interface revision: We’ll be redesigning Copac’s user interface, focusing on areas of usability and navigability of search results. We are aware that the sheer size of our database and our current system means that searches can return large, unstructured result sets that do not facilitate users finding what they need.  Addressing this is a major priority.  We’ll be building on the CERLIM usability report we recently commissioned (more on that in another post) and also drawing on the expertise of OPAC 2.0 specialists such as Dave Pattern.  We’ll also be working consistently with users (librarian users and researcher users) to monitor and assess how we’re doing.

(ii)    Database Restructuring: A more usable user interface is going to critically rely on a suitable restructuring of Copac’s database. Particularly, we are centrally interested in FRBR (Functional Requirements for Bibliographic Records) as a starting point for a new database structure. We anticipate that whatever we learn as we undertake this piece of work will be of interest to the broader community, and plan to disseminate this knowledge, and update the community via this blog.

(iii)    De-duplication: The restructuring implies further de-duplication of Copac’s contents, and so we’re also developing a de-duplication algorithm.  Ideally we would like to see the FRBR levels of work, expression, manifestation and (deduplicated) item being supported, or a pragmatic version of the same.

The end user benefits:
1.    Searches are faster and more effective (Copac database is more responsive and robust; users are presented with a more dramatically de-duplicated results view)
2.    Search-related tasks are easier to perform (i.e. the flexibility of this system will support the narrowing/broadening of searches, faceted searching, personalising/sharing content)
3.    Access to more collections (Copac database is able to hold more content and continue to grow)

So there we have it.  It’s going to be quite a year for the Copac team.  If you have any questions, comments or suggestions you’d like us to take on board, do leave a comment here or email us.  (Not that this will be the only time we ask!) We can also be chatted to via twitter @Copac.

Well Amazon profits a bit.  Last week I busily printed off a spate of £35 Amazon certificates; these are being used as incentives for those willing to spend a few hours with the Copac interface and the CERLIM team (the Centre for Research in Library and Information Management, conveniently located just down the road at MMU).  As we start to plan some (not inconsiderable) overhauls to the service, the time seemed very much right for undertaking some serious usability testing too. As we begin to develop new features for users, including some personalisation tools, it’s more than necessary to take a reality check on how much this feature creep is going to affect users.  So, over the next few weeks we have tasked the research specialists at CERLIM to help us better understand how our users navigate (or don’t) the current interface,  and also provide us with concrete ideas on how our new interface should look as we redevelop over the next year.    They’re going to be using a mixture of search tasks, interviews and structured focus groups, and have managed to engage a good sample of ‘typical’ users (i.e. researchers and postgrads from a range of disciplines).  We know the findings are going to be invaluable (even while we brace ourselves, just a tad;-)).

Last Friday, Shirley and I headed down to London for the TiLE workshop: ‘”Sitting on a gold mine” — Improving Provision and Services for Learners by Aggregating and Using ‘Learner Behaviour Data.’ The aim of the workship was to take a ‘blue skies’ (but also practical) view of how usage data can be aggregated to improve resource discovery services on a local and national (and potentially global) level. Chris Keene from the University of Sussex library has written a really useful and comprehensive post about the proceedings (I had no idea he was ferverishly live blogging across the table from me — but thanks, Chris!)

I was invited to present a ‘Sector Perspective’ on the issue, and specifically the ‘Pain Points’ identifed around ‘Creating Context’ and ‘Enabling Contribution.’ The TiLE project suggests a lofty vision where, with the sufficient amount of context data about a user (derived from goldmines such as attention data pools and profile data stored within VLEs, library service databases, institional profiles — you know, simple enough;-) services could become much more Amazon-like.  OPACs could suggest to users, ‘First Year History Students who used this textbook, also highly rated this textbook…’ and such. The OPAC is thus transformed from relic of the past, to a dynamic online space enabling robust ‘architectures of participation.’

This view is very appealing, and certainly at Copac we’re doing our part to really interrogate how we can support *effective* adaptive personalisation. Nonetheless, as a former researcher and teacher, I’ve always had my doubts as to whether the Library catalogue per se, is the right ‘place’ for this type of activity.

We might be able to ‘enable contribution’ technically, but will it make a difference? An area that perhaps most urgently needs attention is research on the social component and drivers for contributing user-generated content.  As the TiLE project has identified, the ‘goldmine’ here to galvanise such usage is ‘context’ or usage data. But is it enough, especially in the context of specialised research?

As an example of the potential ‘cultural issues’ that might emerge, the TiLE project suggests the case of the questionably nefarious tag ‘wkd bk m8’ which is submitted as a tag for a record. They ask, “Is this a low-quality contribution, or does it signal something useful to other users, particularly to users who are similar to the contributor?”

I’d tend to agree the latter, but would also say that this is just the tip of the iceberg when it comes to rhetorical context. For example, consider the user-generated content that might arise around contentious works around the ‘State of Israel.’ The fact that Wikipedia has multiple differing and ‘sparring’ entries around this is a good indicator of the complexity that emerges. I would say that this is incredibly rich complexity, but on a practical level potentially very difficult for users to negotiate. Which UGC derived ‘context’ is relevant for differing users? Will our user model be granular or precise enough to adjust accordingly?

One of the challenges of accommodating a system-wide model is the tackling of semantic context. Right now, for instance, Mimas and EDINA have been tasked to come up with a demonstrator for a tag recommender that could be implemented across JISC services. This seems like a relatively simple proposition, but as soon as we start thinking about semantic context, we are immediately confronted with the question of which concept models or ontologies do we draw from?

Semantic harvesting and text mining projects such as the Intute Repository Search have pinpointed the challenge of ‘ontological drift’ between disciplines and levels. As we move into this new terrain of Library 2.0 this drift will likely become all the more evident.

Is the OPAC too generic to facilitate the type of semantic precision to enable meaningful contribution? I have a hunch it is, as did other participants when we broke out into discussion sessions.

But perhaps the goldmine of context data, that ‘user DNA,’ will provide us with new ways to tackle the challenge, and there was also a general sense that we needed to forge forward on this issue — try things out and experiment with attention data.  A service that gathers that aggregates both user-generated and attention/context data would be of tremendous benefit, and Copac (and other like services) can potentially move to a model where adaptive personalisation is supported.  Indeed, Copac as a system-wide service has a great potential as an aggregator in this regard.

There is risk involved around these issues, but there are some potential ‘quick wins’ that are of clear immediate benefit. Another speaker on Friday was Dave Pattern, who within a few minutes of ‘beaming to us live via video from Huddersfield’ had released the University of Huddersfield’s book usage data (check it out).

This is one goldmine we’re only too happy to dig into, and we’re looking forward to collaborating with Dave in the next year to find ways to exploit and further his work in a National context.  We want to implement recommender functions in Copac, but also (more importantly) working at Mimas to develop a system for the store and share of usage data from multiple UK libraries (any early volunteers?!)  The idea is that this data can also be reused to improve services on a local level.   We’re just at the proposal stage in this whole process, but we feel very motivated, and the energy of the TiLE project workshop has only motivated us more.

If you’d told me a bit more than a year ago that I’d be getting all excited about the radical potential of library circulation data, well…

This afternoon we had an interesting chat with Dave Pattern from the University of Huddersfield (he of Opac 2.0 and ‘users who borrowed this also borrowed…’ fame).  We’re hoping to collaborate with Dave to see how his important work can be taken forward on a national level.  Dave is about to release the Huddersfield circulation data (anonymised and aggregated) to the community and he’s hoping it will trigger some debate and ideas for developments.   This certainly is a real opportunity for people in our field.  On our end, we’d like to figure out how we could develop a similar feature for Copac, but also look at how to bring more libraries into the mix — contributing more data so those ‘recommendations’ are more effective.

Dave and I both sit on the TILE reference group, and there has been some important work going on in that project about the potential ‘goldmine’ of attention data we’re all sitting on at institutions and data centres.  TILE recommendations suggest the development of an attention-data store service.  Frankly, the sheer scale of this type of all encompassing undertaking gives me headpsin, but a service for the storage and open share of circulation data less so.  In fact, JISC has also recently tasked Mimas and EDINA to propose work around ‘Personalised Search and Recommendation Engines,’ so there’s real scope to think carefully about what such a service might look like.

Goldmine indeed — I’m speaking (from my ’sector perspective’) at the TILE meeting next week.  The focus of the meeting is to look at how we can improve services for learners by aggregating and using learning behaviour data.  For our part, I am keen to see where this work with circulation and attention data can take us, and I’m looking forward to putting some thoughts together on this score for the meeting.

Last Thursday members from the D2D team met up with people from the DPIE 1 and DPIE 2 projects, as well as Paul Walk (representing the IE demonstrator project). The aim was to talk ‘personalisation’ developments for the JISC IE. It’s impossible to cover the entire scope of discussion here (we were at it most of the day). As you might predict, it was a day of heated but engaging debate around a topic that is technically and socially complex. As we think about the strategic future of services and cross-service development, and there are serious questions marks over which direction we’re headed in terms of personalisation (and, of course, if it’s even possible to talk of ‘a’ direction).

The key practical aim of the meeting was to share the personalisation aspects of D2D project work, and also to discuss the recommendations of the two DPIE reports. The D2D work includes some development of personalisation components for Copac, components we are referring to cautiously as ‘lightweight’ for now. One way in which we plan to ‘personalise’ the service for users is by offering a ‘My Local Library’ cross-search, achieved (we hope — we’re very much in early phases here) via a combination of authentication and IP recognition used to identify users’ geographical location, and then a cross-search of local institutional library holdings data via Z39.50 targets.

In addition, by next the middle of next year, Copac users will be able to save marked lists of records and export them into other 2.0 environments via an atom feed (I’ll let Ashley write the more technical post on that development). Further down the line (i.e. beyond the next six months) we are interested in providing tools for users to annotate, bookmark and tag these records, but we also want to make sure that any such developments are not made in isolation and are ‘Copac’-centric — there’s a lot to explore here, obviously.

In and of themselves, these developments are not especially complex — the latter is an example of personalisation via ‘customisation’ (to use JISC definitions) where users explicitly customise content according to their own preferences. What I am especially interested in, however, is how saved lists (’My Bibliography?’) could be used to potentially support adaptive personalisation (this is what Max Hammond, co-author of the DPIE 2 report wryly referred to at the meeting as ’spooky’).

Dave Pattern’s experiment with using circulation data to ‘recommend’ items to University of Huddersfield library users is well known, and I hope the first step towards some potentially very interesting UK developments. On this end, we’re interested in knowing if there is anything similar to be gleaned from saved personal lists — ‘users with this item in their saved lists also have…’ (or something along those lines). This terrain is very much untested, and one of the critical issues, of course, is uptake. Amazon’s recommender function is effective due to the sheer number of users (effective *some* of the time, that is — we all have ‘off-base’ Amazon recommendations stories to tell, I admit). And this is just one small example of how adaptive personalisation of a service like Copac (or other JISC IE services) might work — there are also opportunities around capturing attention data, for instance.

The DPIE 2 report urges extreme caution in this regard. It raises some very pointed questions about how JISC and its services should approach adaptive personalisation. Too often, the authors warn, ‘personalisation’ is established as a specific goal, with the assumption that ‘personalisation’ is intrinsically valuable. In this context, change is technology rather than user driven, which is fine for experimental and demonstrator work, but high-risk for established services with a strong likelihood for failure. They question how helpful definitions of Personalisation put forth by JISC are in carrying forward a development agenda (Customisation; Adaptive Personalisation based on Data held elsewhere (APOD); Adaptive Personalisation based on User Activity (APUA). This definition “provides a mix of concepts from data capture to functionality, rather than setting out the logical link between a source of data about a user, a model of that user, and an approach to providing the user with a personal service” (17). Also missing is a robust benefits mapping process — “there is little analysis of the benefits of personalisation, beyond an assertion that it improves the user experience” (20). The report concludes:

Complex developments of “personalisation services” and similar should not be a current
priority for JISC. It seems unlikely that an external personalisation service will be able to
generate a user model which is detailed enough to be of genuine use in personalising
content; user preferences are probably not broadly applicable beyond the specific resource
for which they are set, and user behaviour is difficult to understand without deep
understanding of the resource being used. Attempting to develop user models which are
sufficiently generic to be of use to several services, but sufficiently detailed to facilitate useful
functionality is likely to be a challenging undertaking, with a high risk of failure. (26)

These are somewhat sobering thoughts, especially in a climate of personalisation and 2.0 fervour, but overall the report is useful in considering how to tread the next steps in development activity. Key for us is this issue of the user model — can we (Copac? SUNCAT? JISC?) develop one that is likely to be of use to several services? My hunch right now is ‘no.’ We know very little concrete about researchers’ behaviour and how they might benefit from such tools (interestingly, both DPIE 2 reports focused on benefits for undergraduate students, when most of the services in question are largely used by researchers). About humanities researchers, we know even less (much of the interesting work around online ‘Collaboratories’ centres on the STEM disciplines). Apparently JISC is about to commission some investigative work with researcher-users, and here at Mimas a team is about to undertake some focus group work with humanities researchers to determine how personalisation tools for services like Copac, Intute and the Archives Hub could (or could not) deliver specific benefits to their work. I’m sure this research will prove very useful.

We’re urged to ‘proceed with caution,’ but we proceed nonetheless. At Copac we’re taking a long hard look at what a personalised service might look like, and accepted that some risk-taking is likely forecast for the future. I’m very interested to know other’s opinions on a possible recommender function for Copac — at what level could such a tool prove useful, and when might it possibly be obstructive? Personally, I have used the ‘People who have bought also bought’ feature in Amazon quite extensively as a useful search tool. I am less likely to take up the direct recommendations that Amazon pitches at me through my ‘personalised’ Amazon home page, however. (This comes, in part, from making purchases for a six year old boy. If only I could toggle between ‘mummy’ and ‘professional’ profiles…. now there’s a radical thought).

Bored with the same old books? Not now Chetham's catalogue is going into Copac...

We’re not sure what this fellow is reading, but we agree that the remedy is surely to be found in Copac Thanks to the inclusion of libraries like Chetham’s (the oldest public library in the English-speaking world, no less) our users are going to be able to discover some fascinating and rare materials, many of them unique to the UK. The Challenge Fund has aided us in bringing in catalogues from fifteen such libraries (the Tate Gallery, Lambeth Palace, Kew Royal Botanical Gardens, to name but a few).

This is a long tail made up of not a few long titles. We particularly like this one from Chetham:

Felix Folio: the hawkers and street dealers of the north of England manufacturing districts; including quack doctors, cheap Johns, book-sellers by hand, bookstall-keepers, watch-sellers, needle-dodgers, “land sharks,” alias “turnpike sailors,” alias “duffers,” nut-sellers, bird-sellers, wild-fowl dealers, “dollopers,” flying stationers, street ballad sellers, cheese hawkers, cum multis aliis. Being some account of their dealings, dodgings, and doings, by Felix Folio [pseud. of John Page]

(and you can even buy a facsimile)

p.s. anyone know what a ‘dolloper’ is ?

The blog’s been silent this week. Ashley’s getting on with the practical business of development, and I’ve been spending time writing up content for my presentation at the International Internet Librarian conference, as well as a presentation to the Mimas Board of Directors on D2D and the future of Copac (more on that next week).

I’m speaking in a panel on “The OPAC and the Library of the Future” at ILI, and writing up my thoughts has been a great opportunity to hash out some of the tensions and challenges surrounding the whole Copac 2.0 thing.   I now think ILI “owns” what I’ve submitted to them (and it’s not available online yet). So to avoid any handslapping (and to echo Austen Powers) “allow myself to quote myself”:

As Copac and its stakeholders think strategically about an approach to Web 2.0 and specifically customisation and adaptive personalisation, as I will discuss, multiple issues and tensions emerge. Central among them is striking that delicate balance between ‘openness’ and ‘control.’ We want to promote an ethos where Copac data is opened up (via APIs for instance) and made available for the community in as useful form as possible, but we also recognise that this means devolving control over what happens to that data. At the same time, as a collective resource comprising of over 50 UK libraries, we are also considering how Copac is uniquely positioned as an aggregator and can, to use Lorcan Dempsey’s phrase: “reinforce the value of network effects,” and so increase “gravitational pull” towards a concentrated service that supports UK focussed research. [1]By gathering ‘personalisation’ or ‘intentional’ data, Copac (and other JISC bibliographic services) can potentially move to a model where adaptive personalisation is supported, including those desirable Amazon-like recommender functions. We can potentially help to begin to yield that ‘long tail’ of under-used or little known UK library resources, for example those unique and rare items now incorporated into Copac via the Kew Botanical Gardens, the Natural History Museum, or Royal College of Surgeons.

This, as yet, is a tentative and unformed vision for Copac, a vision we are now attempting to refine and focus. This future for the service is by no means set in stone, and our ideas are very much exploratory at this stage. Copac occupies a single position in a complicated terrain which encompasses the UK resource discovery and library landscape and, of course, the much larger global terrain occupied by WorldCat, Google, Google Books, and Amazon.com. Our strategic planning is necessarily complex. Nonetheless, we are eager to open up conversations about the future of a service like Copac, and at the close of this talk would like to invite feedback and insight over the strategic directions Copac might take, and new questions that emerge.

So that gives you the gist of what I’m planning to talk about, and I am hoping it will be a good opportunity to get some feedback.  In the meantime, any thoughts or comments here are very welcome. Happy friday:-)

As Ashley has just posted, we’ve just reinstated the links to Google Books that were appearing in the right-hand column of relevant records. Back in March we were pleased to be among the throng of those incorporating the new Google Books API. If Google’s mission is to ‘organize the world’s information and make it universally accessible and useful,’ who are we to argue? What self-respecting library service wouldn’t want to be a part of a project that promotes the Public Good?

Then something unusual happened — we got complaints. Not a great many, but still a vociferous few who questioned why Copac would give Google ‘personal data’ about them as users. Several of us in the team went back and forth over whether this was actually the case. My own opinion was that a) this was not ‘personal’ data, but usage data, and therefore not a threat to any individual’s privacy, and b) even if we were giving Google a little bit of something about our users and how they behaved, what does it matter if the trade-off is an improved system? Nonetheless, we went ahead and added that small script so that Google only spoke to the Copac server. No dice.

I was not all that surprised that our attempt at a workaround wasn’t effective (it would have been nice to have heard something back officially from Google on this front, but we’ll live). I am still wondering if it matters, though. Does it makes sense that we ‘pay’ Google for this API by giving them this information about Copac users — their IP addresses and the ISBNS of books they look at? (Is this, in fact, what we’re doing? Paying them?) Isn’t all this just part of the collective move toward the greater Public Good that the entire Google Books Search project seems to be about?

Ultimately, right now, yes. This is the trade-off we’re willing to make. So we’ve reinstated the links, but also added an option under Preferences for now to allow users to de-googlise their searches. Turning off the feature for good would be reactionary to say the least (and perhaps, more to the point, in the political landscape in which Copac operates, *seen* as reactionary). Right now, if you’re in the ‘Resource Discovery’ business, then a good relationship with the most ubiquitous and powerful search engine in the world is of no small importance.

Indeed, behind the scenes, our colleagues at RLUK have been working with Google on our behalf to sign an agreement which will mean that Google can spider Copac records. The National Archives has recently done this, and from what I hear anecdotally from people there, it’s already having a dramatic impact on their stats — thousands users are discovering TNA records through Google searches, and so discovering a resource they might not have known about before. We are hoping that users will have a similar experience with Copac, especially those looking for unique and rare items held in UK libraries that might not surface through any other means. We are eager to see what sort of impact a Google gateway to Copac will have, and we know it can only enhance the exposure of the collections. We’re also exploring this option for The Archives Hub.

Of course, this also means that Google gets to index more information about Copac web searches. David Smith’s article last week “Google, 10 years on. Big Friendly Giant or Greedy Goliath?” highlights some of the broader concerns about this. To what extent should we be concerned about the fact that a corporation is hoovering up information about our usage behaviour? I am always suspicious of overblown language surrounding technology, and Smith’s article does invoke quite a number of metaphors connoting a dark and grasping Google that we’d better start keeping an eye on, “Google’s tentacles are everywhere.”

But invokations of the ‘Death Star’ notwithstanding (!) I think we’re all learning to be a bit more cautious about our approach to Google. It may not be the Dark Lord, but it’s no ‘Big Friendly Giant’ either. For now, we’re pleased to be able to plug in Google’s free API (thank you, Google) and that Copac will soon be searchable via the engine. But nothing is entirely free, or done for entirely altruistic purposes — this is business after all. We just have to keep that in mind and talk constructively and openly about what we’re willing to pay.

[Updated to add: Likely much too late in the game, but I've just spent an hour or so listening to The Library 2.0 Gang's podcast with Frances Haugen, product manager for the Google Book Search API.  Tim Spalding (LibraryThing) and Oren Beit-Arie (Ex Libris) were among those to pose some of the tougher questions surrounding the API and specifically the fact the it only works client-side and forces the user into the google environment.  According to Frances, future developments will include a server-side API, and that an ultimate goal would be to move to a place where the API can be used to mash up data in new interface contexts.  We'll certainly be watching this space:-)]

Since joining the Copac team at Mimas earlier this year, it has struck me that there’s a certain facelessness to Copac. Copac just ‘is’ and talented people working industriously behind it are largely invisible — which has made sense, of course. We have a hunch that Copac users don’t really care too much about how we’re tackling new API developments or if we’re Shibbolized or not.

But there’s another community out there, the one comprising of professionals, librarians, academics, techies and geeks, the one that *does* get all a twitter about bibliometrics, FRBR, Open Source, data-sharing, and Library 2.0. The one comprising of People Like Us. And so we decided it was time to get out from behind the curtain and join in the conversation. We not only want to share what we’re up to behind the scenes, but also be part of the larger conversation — share our knowledge, get feedback, and learn so we can move Copac forward.

My colleague Ashley has just christened this here blog with a post on our new OAI-PMH interface (so please, harvest away and let us know how you get on) and we hope this will be the first of many posts about our developments — not just information, but voicing up about the challenges we’re tackling around development, including Web 2.0 and the way in which Copac might support customisation or adaptive personalisation, or the potential contexts for reuse and sharing of Copac data. In addition, we’re working with EDINA on the JISC funded D2D project, and so over the next year we’ll be working with our colleagues over in Edinburgh to join up Copac with Zetoc and SUNCAT, and also to think about new ways in which this collective data along with new tools can better support the workflows of Scholarly Communication.

There’s going to be a lot to write about, and we know one of our main challenges will be keeping this blog up-to-date. Watch this space, and hopefully something new will appear on it every so often:-). Meanwhile, get to know your hosts — Ashley and Joy.

(p.s. we’ll be building up our blogroll over the next few weeks, but if you find something you think we’d find interesting in your blog-reader do leave us a comment and point us to it)