I wonder if some of these issues might be relevant within the context of the UK RepNet project which is holding a meeting in London on 21st Jan – http://www.rsp.ac.uk/events/supporting-and-enhancing-your-repository/

PS I’ve realised that nesting comments doesn’t really work, which is why this comment is out of sequence.

On the wider issue – resources that lose their way home when out in the wild – I think it makes sense that on ingest any content gets the URL to its catalogue record (the IR page in this instance) embedded. While a coverpage could contain that information, it’d be nicer if it were machine readable.

I’m aware of two schools of thought in the preservation community about this – one says embed as much metadata as possible in the file such that it is self-describing. The other says a link to a catalogue record is enough. The latter relies on the persistence of the catalogue – which not everyone can guarantee and as such is perhaps more of a risk.

Not sure I necessarily see that argument myself and is fairly standard practice from several major publishers as well as repositories I think and strikes me that it’s rather like arguing a book-cover is inconvenient as it’s such a faff to open it and get past that page with the isbn and copyright on it! The effect on pdf metadata and how that is indexed by search engines is a separate issue.

The example linked above which is originally from our repository at Leeds Met and now has multiple cover sheets is more of a practical issue. Nothing wrong with sourcing papers from other repositories to increase exposure etc; I’ve just uploaded our paper from or2012 in Opus – http://opus.bath.ac.uk/30226/ – to our repository at Leeds Met and replaced the cover sheet with our own – http://repository.leedsmet.ac.uk/main/view_record.php?identifier=7827&SearchGroup=Research

I’m not sure whether the Portsmouth repo manager felt they should retain the Leeds Met cover sheet to preserve provenence or if it was merely an oversight (I should probably have also removed the existing cover sheet(s) when I originally uploaded!) in any case I agree the final result is somewhat unfortunate with 6 pages before the actual content of the research itself :-/

If you go to the page about the paper on A Challenge to Web Accessibility Metrics and Guidelines: Putting People and Processes First you will be able to view a thumbnail of the PDF (with no cover page) which was uploaded by one of my co-authors. You can also download the PDF.

In both cases, you do not need to sign in to the service to access the PDFs,

Brian

We have had discussions about coversheets in the past, and as you note, have worked to solve some issues. Can I reiterate please, that the coversheet is a policy decision and that actually due the lack of identifying content on many pdfs we receive, it’s not a bad decision. In light of this, we are not going to drop the coversheet but perhaps there is potential for the Eprints plugin to draw more/better metadata onto the page to aid SEO?

Am I right in thinking you need to subscribe to ResearchGate in order to view full text?

Also, what’s so bad about a coversheet from a users POV? Granted the machine-readable issues but I often find it easier to find identifying metadata about a paper from the coversheet than from the document itself, particularly on post-prints. Am I alone here?!

Kara

Thanks for the comment.

Your question “does it matter if the rare and patchy instances of author-created metadata gets over-written or otherwise distorted?” is a good one.

The example provided by Ingmar Koch (of template metadata which is not updated) illustrates that such embedded metadata is used. In this case, the authors may well have preferred it if the metadata had been lost as part of the creation of a cover sheet! However this does show how embedded metadata is being processed by Google. In addition, as I suggested in my post, we could find that other third party services processed the metadata associated with the object, rather than metadata which is decoupled form the resource.

However if there are concerns that the metadata will be poor (as in Ingmar Koch’s example) perhaps there is a need to be honest about this, and explicitly state that embedded metadata will be removed prior to the resource being deposited in the repository.

As noted on Twitter, we often convert Word docs into PDFs on behalf of our academics here at City to put them into City Research Online- it’s rare to get “author final” versions in PDF format. I suspect that even when we do get PDFs, it’s rare to have “good” embedded metadata in that PDF.

On the question of discoverability, I had assumed that the structured metadata provided at Eprint/DSpace/other repository software record level did the job here (as opposed to metadata embedded within the PDF itself). Certainly records in City Research Online are highly ranked in Google and are harvested by Google Scholar, BASE, OAIster etc. If this is the case, does it matter if the rare and patchy instances of author-created metadata gets over-written or otherwise distorted?

Neil.

Need more than 140!

Historically yes, I have added cover pages to PDFs. I’m not sure how typical my workflow is though as, mainly due to software idiosyncracies (I don’t have EPrints and its nice workflow), I have always offered a fully-mediated service which typically involves me soliciting a suitable (author produced) version of a paper, usually as a word doc(x) and converting it myself with Acrobat and manually adding a cover page. I believe there is a plug in for EPrints though that automatically adds a cover page? In any case, my manual workflow will just result in a PDF with no metadata unless I add it manually. If these are subsequently picked up by Google I just get “Leeds Metropolitan University Repository” in the search result i.e. indexed from the text of the PDF itself.

All this has been on my mind recently as we are in the process of implementing Symplectic and integrating with the repository such that I should finally be able to implement a self-deposit workflow, but I anticipate folk are likely to upload word files rather than convert them to PDF…so not sure how my workflow will develop; I’ll obviously offer guidance, but I’m keen to procure content in any format, whether I intervene in the workflow, convert to PDF, add a nice coversheet and metadata depends on how onerous that becomes.

Nick