> It's an excellent point. The resolver's knowledgebase needs to know
> which issn a vendor has bundled content under, and ideally will be
> able to access that content no matter the issn/eissn in the OpenURL
> metadata. I'm thinking of a particular vendor that uses issn in the
> url syntax, but wi
It's an excellent point. The resolver's knowledgebase needs to know
which issn a vendor has bundled content under, and ideally will be
able to access that content no matter the issn/eissn in the OpenURL
metadata. I'm thinking of a particular vendor that uses issn in the
url syntax, but without a k
>>
I agree; issn is not an identifier for an article. But in general, a
resolver should be smart enough to know what serial is meant even if a
variant issn is supplied.
>>
To prevent multiple searches, the resolver has to know how a title is
referenced in the target source. This requires precalcul
I'm not sure, it seems to me that it could never be harmful, and could
sometimes be helpful, for the CO generator to send all the information it has.
Sure, a good link resolver _should_ be able to resolve any valid ISSN, it
shouldn't need multiple ISSNs. But we all know that 'should' doesn't a
Multiple rft_id's is a fine solution to isbn for a book citation---but if
you've got an article citation, that lives in a particular journal with an
issn, and you know the issn of that journal---please don't put it in a rft_id.
An ISSN is not a good identifier for one particular article IN the
I agree; issn is not an identifier for an article. But in general, a
resolver should be smart enough to know what serial is meant even if a
variant issn is supplied.
I do not agree that it would be helpful for generators to send
multiple issn's. They currently can send issn and eissn; if the
reso
Worldcat Link Manager will use the last valid (including check digit)
ISBN in the OpenURL, whether in an rft_id or in an rft.isbn. Currently
xISBN is used in the response if it is turned on. Multiple rft_id is
valid according to spec.
On Feb 19, 2008, at 9:26 AM, Ross Singer wrote:
Actually, th
Jonathan Rochkind wrote:
One thing I
think I feel like we've learned from many of our community's recent
metadata initiatives is the importance of creating standards in such a
way that they can be further developed and/or extended in a backwards
compatible way. Ie, an OpenURL 1.1 or something, th
Be careful though, please don't send an rft_id ISSN identifier for an
_article level_ metadata package. OCLC does this. It's wrong, as the
ISSN does not serve as an identifeir for the _article_ cited, but rather
for the journal it's in. Until I figured out what was going on, this
caused some bugs
Ah, you're referring to rft_id, and I was looking at the ISBN element in
the KEV Book format. So using rft_id would work.
The reason for multiple ISBNs is that many MARC records have ISBNs for
the hard copy and the paperback. Without going through some gyrations
you don't know which is which, alt
Actually, this:
http://alcme.oclc.org/openurl/servlet/OAIHandler/extension?verb=GetMetadata&metadataPrefix=mtx&identifier=info:ofi/fmt:kev:mtx:ctx
indicates that multiple rft_ids *are* valid, and, in fact, would have
to be, since you could very easily have a DOI and a PMID and, say, a
SICI.
I hav
Actually, the max occurrence of ALL of the KEV keys is 1 except for "au"
(which is unlimited). I remember discussions in which we acknowledged
that one key NE one value, eg you could input multiple values if your
recipients were in agreements (a poor excuse, I know). Thus:
"isbn:;isbn:". M
I'm not sure if you can do that in the KEV format that OpenURL uses,
although you could do it in the XML format. But it still woudln't mean
exactly what William wants it to mean--and most existant link resolvers
wouldn't neccesarily do the right thing with it.
OpenURL can be a bear sometimes.
I
Hi William,
According to the book KEV format (defined here:
ttp://tinyurl.com/2psmkq) the max occurrence of the isbn key is 1. I'm
assuming that by extension that means that the rft. (i.e.,
rft.isbn) form is also limited to one occurrence. So specifying
multiple ISBNs that way is a no go.
You can
I'm hep to the COInS scene now and am using it in some lists of books I'm
generating. For some of the books I know multiple ISBNs. Can I include
them all in one COInS span somehow? Doing one individually makes my
OpenURL Referrer extension clutter up the page with a lot of links.
I looked at t
15 matches
Mail list logo
