Dirty data or how to find out whether a COinS is valid or not
sieh...@googlemail.com
Last year we implemented COinS in our library catalouge and it works
pretty fine in most cases. But for some records Zotero just produces
an error message without further information. For example this COinS
specifies a journal with title, ISSN and date:
<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info
%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rfr_id=info%3Asid%2Focoins.info
%3Agenerator&rft.genre=journal&rft.title=American+behavioral
+scientist&rft.stitle=American+behavioral
+scientist&rft.issn=0002-7642&rft.date=1960"/>
Please note that this is not a journal article but a journal - which
is probably the reason why Zotero does not eat it. But http://generator.ocoins.info/
can resolve the OpenURL without complaining, so who is wrong? Is this
a valid COinS or not?
If there is no way to find out whether a given COinS is valid, I
strongly doubt that COinS is the right direction at all. Provider of
bibliographic data on the one side and provider of resolvers and
services like Zotero and RefBase have to agree upon metadata standards
- but beside the Brief guides to Implementing OpenURL 1.0 Context
Object for Journal Articles and Books at http://ocoins.info/ (which I
don't know how to automatically test agains by the way) I could not
find any information what the standard is. If there is no agreement on
how to encode bibliographic data in COinS, everyone will do it the way
he thinks and we get masses of dirty data that can not be used
interoperably.
Greetings,
Jakob
Daniel Chudnov
> If there is no way to find out whether a given COinS is valid, I
> strongly doubt that COinS is the right direction at all.
This is an excellent point, and one I was just discussing with
somebody else yesterday. The key thing to remember is that COinS is
really just OpenURL - it's only a convention for rendering an OpenURL
in HTML. Which means that we inherit all the benefits and drawbacks
that entails, one of which is that there's no clear validation
strategy for OpenURLs.
In my experience, it's surprisingly easy to dig into Zotero's
javascript source and find the COinS handler to see how its logic maps
to the fields you're providing. But it's also difficult if, as you
are, you're trying to provide a COinS for something that isn't a book
or journal article - the two most common OpenURL cases, for which
Zotero's logic is optimized to some degree (and reasonably so). It
might just mean having to shoehorn an extra value into an OpenURL
profile implementation that you wouldn't otherwise use in a way that
doesn't quite make sense, but nonetheless works.
More directly to your point, though, maybe there is an opportunity for
a handful of COinS producers/consumers to write a simple set of
implementation guidelines to say "here's the bare minimum for these n
use cases"?
-Dan