 |
 |
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 resolvers knowledgebase is good, then sending it multiple issns will never help and will often degrade its performance. I think its sucky to craft OpenURL metadata that caters to substandard resolvers. On Feb 19, 2008, at 11:09 AM, Jonathan Rochkind wrote: > 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 in Umlaut. > > It _would_ be nice to send multiple ISSNs even for an article-level > citation. Let's say the generator of the OpenURL happens to know that > there are several variant ISSNs for the publication, that identify > differnet manifestations, but any of which are valid for the given > article citation. It would be helpful for the generator to send them > all > along, in case the link resolver knows about some but not all of them, > to increase the chances that the link resolver will properly > 'recognize' > the citation. > > But, it unfortunately can't be done. It's not the end of the world to > realize that OpenURL isn't perfect (what is? By trying you learn from > your experience to do better next time), but I'm unconvinced that this > is actually desirable in any way instead of an oversight. 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, that was backwards > comptable so it could be sent to resolvers that knew no more than 1.0 > without problems. This has to do with both the design of the > structure/syntax of the metadata, as well as the design of the > _processes_ of maintenance, to make this kind of extension and > development not too cumbersome socially. > > Jonathan > > Karen Coyle wrote: >> 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, although for purposes like ILL >> either is >> valid. There are also multi-volume works that each get an ISBN. >> >> Like other FRBR "levels" manifestation has a fairly wide range of >> ambiguity. A book simultaneously published in two countries... is >> that >> one manifestation or two? What if they each get a separate ISBN? A >> hardback and trade paperback that come out at the same time, where >> the >> only difference is the cover... and the ISBN? >> >> Although I often use the shortcut of "ISBN = manifestation" the >> fact of >> it is that ISBNs are publisher inventory and sales numbers and are >> used >> in ways that are convenient for publishers. They also get mis- >> assigned >> frequently, as some tests being run on bib data at the Open Library >> are >> showing. >> >> kc >> >> Ross Singer wrote: >>> 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 have no idea what any resolver would do with this bundle of ISBNs, >>> of course. It also seems somewhat contrary to the intention of the >>> Book metadata format, since I think it's (in my murky view of FRBR-y >>> terms) trying to define a manifestation rather than the expression >>> level that Bill is trying to use it for. I could be weaving in my >>> own >>> interpretations and biases there. >>> >>> An alternative would be use by-reference context objects and then >>> make >>> the context objects available as XML. You could have multiple >>> context >>> object available in one XML document this way. A combination of >>> COinS/unAPI could make something like this possible. >>> >>> -Ross. >>> >>> On Feb 18, 2008 6:53 PM, Karen Coyle <[log in to unmask]> wrote: >>>> 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:3333;isbn:8888". My only memory for why max=1 for all of >>>> these is >>>> that it has to do with the fact that there is no structure or >>>> dependency >>>> in KEV, so an OpenURL with keys >>>> &rft.au=nnn&rft.title=ttt&rft.au=pppp&rft.title=rrrr >>>> isn't interpretable in terms of what authors go with what titles. >>>> Why >>>> the exception for au but for no other fields? My memory fails me >>>> here. >>>> Undoubtedly it made sense at the time. >>>> >>>> kc >>>> >>>> >>>> Jay Luker wrote: >>>>> 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.<m-key> (i.e., >>>>> rft.isbn) form is also limited to one occurrence. So specifying >>>>> multiple ISBNs that way is a no go. >>>>> >>>>> You can however specify multiple referent identifiers. From the >>>>> KEV >>>>> Context Object format matrix (http://tinyurl.com/2r5hsc): >>>>> "Multiple >>>>> instances of rft_id do not indicate multiple Referents, but rather >>>>> multiple ways to identify a single Referent" >>>>> >>>>> So I *think* what you could do is this: >>>>> >>>>> "rft_id=urn:isbn:<isbn1>&rft_id=urn:isbn:<isbn2>&..." >>>>> >>>>> Also, I'd be remiss not to point you to a more authoritative >>>>> list for >>>>> OpenURL questions: http://listserv.oclc.org/scripts/wa.exe?A0=OPENURL >>>>> . >>>>> Although I'm sure there's plenty of overlap in interest/ >>>>> knowledge in >>>>> the subject between the lists. >>>>> >>>>> -- >>>>> Jay Luker [log in to unmask] >>>>> Software Engineer, Ex Libris Inc. >>>>> (617) 332-8800, x604 http://www.exlibrisgroup.com >>>>> >>>>> On Feb 17, 2008 3:14 AM, William Denton <[log in to unmask]> wrote: >>>>>> 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 the specification but it didn't seem to cover this. >>>>>> generator.ocoins.info only seems to want one one ISBN. Putting >>>>>> multiple >>>>>> rft.isbn variables just makes the last one overpower the earlier >>>>>> ones. >>>>>> >>>>>> Any tips appreciated! >>>>>> >>>>>> Bill >>>>>> -- >>>>>> William Denton, Toronto : www.miskatonic.org www.frbr.org >>>>>> www.openfrbr.org >>>>>> >>>>> >>>> -- >>>> ----------------------------------- >>>> Karen Coyle / Digital Library Consultant >>>> [log in to unmask] http://www.kcoyle.net >>>> ph.: 510-540-7596 skype: kcoylenet >>>> fx.: 510-848-3913 >>>> mo.: 510-435-8234 >>>> ------------------------------------ >>>> >>> >>> >> >> -- >> ----------------------------------- >> Karen Coyle / Digital Library Consultant >> [log in to unmask] http://www.kcoyle.net >> ph.: 510-540-7596 skype: kcoylenet >> fx.: 510-848-3913 >> mo.: 510-435-8234 >> ------------------------------------ >> > > -- > Jonathan Rochkind > Digital Services Software Engineer > The Sheridan Libraries > Johns Hopkins University > 410.516.8886 > rochkind (at) jhu.edu