- From: Guenther, Rebecca <rgue@loc.gov>
- Date: Tue, 14 Dec 2010 17:59:41 -0500
- To: "'Young,Jeff (OR)'" <jyoung@oclc.org>, Karen Coyle <kcoyle@kcoyle.net>, public-lld <public-lld@w3.org>
I think it is the case that anything that is a URI, i.e. is a registered identifier scheme, is called "uri" in 024 and then you look in the URI itself if you need to know more about what kind of URI scheme it is. Maybe we can clarify the language a little better in the MARC documentation. Again, the reason we used source is that it was consistent to the usage in other fields (i.e. that indicator value 7 and the name of the subfield) and we felt these things were close enough semantically. Rebecca -----Original Message----- From: public-lld-request@w3.org [mailto:public-lld-request@w3.org] On Behalf Of Young,Jeff (OR) Sent: Tuesday, December 14, 2010 5:04 PM To: Karen Coyle; public-lld Subject: RE: MARC Authority 001 and Linked Data (was RE: Linked Data URIs in MARC Authorities) Unfortunately, URIs are not defined by their structure. A string may be a globally-unique identifier, but it isn't a URI unless the scheme is registered and conforms to specifications. For example, DOIs are not URIs: http://www.iana.org/assignments/uri-schemes.html The confusion over "source" in the 024 is caused by misalignment of 024 7# (pertaining to "source") vs. 024 8# (pertaining to "type"). http://www.loc.gov/marc/authority/ad024.html This disconnect wasn't a problem until HTTP URIs and domain name/DNS came along with a practical system for registering/coining globally-unique identifiers with the "source" built-in. It might have been better if MARC had coined a new ind1 value for URIs that deferred to the URI scheme to determine "source" (e.g. domain name/DNS). This decision is long past, though, and presumably won't be revisited. I think we're stuck with rationalizing the word "source" as Rebecca suggests. At least MARC21 gives us 024 as a place to identify "the entity named in the 1XX field". As far as I can tell, UNIMARC provides no plausible place to do this. Jeff > -----Original Message----- > From: public-lld-request@w3.org [mailto:public-lld-request@w3.org] On > Behalf Of Karen Coyle > Sent: Tuesday, December 14, 2010 3:23 PM > To: public-lld > Subject: RE: MARC Authority 001 and Linked Data (was RE: Linked Data > URIs in MARC Authorities) > > I guess I just don't consider a URI a "source" -- it's more of a > format. Other sources listed for MARC are things like ISBN, ISSN, ISO, > DOI, EAN. Those all seem to indicate the agency or program that > generates the identifier, not its format. I agree that URI is on the > list, I just don't find it to be in the spirit of the list. (BTW, you > know it's a URI by its format.) > > kc > > Quoting "Guenther, Rebecca" <rgue@loc.gov>: > > > Jeff is correct in how he said it would be coded in MARC. > > > > I'm not sure what Karen is saying here, but 024 $2 is supposed to > > specify the type of identifier (not the agency assigning it) > > represented by the data in $a. URI is on the list of standard > > identifier source codes. If someone wanted to use VIAF identifiers, > > we could add it to the standard identifier list and use it if it > > were not also a URI (for example, an LCCN could be represented as a > > "raw" LCCN and "lccn" is on the identifier list or as a URI where > > the LCCN is the last part of the string). If the VIAF identifier can > > be represented by a URI, you could use $2 uri and the fact that it's > > viaf will be implicit in the identifier itself in 024 $a. > > 024 is a standard identifier field and it is expected that the type > > of identifier is specified in $2. I realize that the documentation > > calls it "Source of number or code"; this is consistent with other > > $2 subfields in other fields, but in the case of 024 "source" refers > > more to being in the list of standard identifier source codes (the > > documentation links to that list). > > > > Rebecca > > > > Rebecca S. Guenther > > Senior Networking & Standards Specialist Network Development & MARC > > Standards Office Library of Congress > > 101 Independence Ave SE > > Washington, DC 20540 > > voice: +1.202.707.5092 > > fax: +1.202.707.0115 > > rgue@loc.gov > > > > > > > > -----Original Message----- > > From: public-lld-request@w3.org [mailto:public-lld-request@w3.org] > > On Behalf Of Karen Coyle > > Sent: Tuesday, December 14, 2010 1:39 PM > > To: Young,Jeff (OR) > > Cc: public-lld > > Subject: Re: MARC Authority 001 and Linked Data (was RE: Linked Data > > URIs in MARC Authorities) > > > > Jeff, my only comment is on the 024 $2. The 024 is kind of a > > catch-all field, as you know, and the $2 is supposed to be the > > source institution or agency for the value in the $a: > > > > $2 - Source of number or code > > MARC code that identifies the source of the number or code. Used > > only when the first indicator contains value 7 (Source specified in > > subfield $2). > > Code from: Standard Identifier Source Codes. > > > > That would indicate that the $2 should be something like "viaf" -- > > although admittedly that doesn't convey the fact that the URI > > represents the entity named in the 1XX field. I would guess that > > with viaf in the $2 (even though it is redundant with the domain > > name, but that could be considered a coincidence) we could agree on > > the meaning of the identifier in practice. The concept of RWOs isn't > > one that MARC recognizes, and for sure not in the 024 field. > > > > kc > > > > Quoting "Young,Jeff (OR)" <jyoung@oclc.org>: > > > >> VIAF is using Corine's suggestion of the MARC Authority 024 to > record > >> the URI that identifies "the entity named in the 1XX field" > >> (aka "real world object" or "non-information resource"). > >> > >> 024 7# $ahttp://viaf.org/viaf/102333412$2uri > >> > >> Contrast that with the URI VIAF coins specifically for the > >> corresponding MARC21 representation (aka " document" or > >> "information > >> resource"): > >> > >> http://viaf.org/viaf/102333412/marc21.xml > >> > >> I would argue that this URI is the de facto "control number" for > >> our > >> MARC21 Authority record and thus belongs in the 001 field. Here's > the > >> spec: > >> > >> http://www.loc.gov/marc/authority/ad001.html > >> > >> Here's what it would look like in context: > >> > >> 001 http://viaf.org/viaf/102333412/marc21.xml > >> 003 OCoLC > >> 024 7# $ahttp://viaf.org/viaf/102333412$2uri > >> > >> Does anyone disagree with this interpretation or imagine a > >> plausible scenario where using an HTTP URI in the 001 would cause problems? > >> > >> Jeff > >> > >>> -----Original Message----- > >>> From: Deliot, Corine [mailto:Corine.Deliot@bl.uk] > >>> Sent: Monday, October 04, 2010 10:11 AM > >>> To: Xavier Agenjo; Karen Coyle; Young,Jeff (OR) > >>> Cc: public-lld > >>> Subject: RE: Linked Data URIs in MARC Authorities > >>> > >>> Dear all, > >>> > >>> Sorry to be coming into this thread a bit late but I thought I > would > >>> point you to the paper that was discussed at MARBI last June on > >>> how to record the ISNI (International Standard Name Identifier) in > >>> MARC bibliographic and authority records as I think it is relevant > >>> to > the > >>> current discussion. > >>> http://www.loc.gov/marc/marbi/2010/2010-06.html > >>> > >>> This extended the definition of subfield $0 to enable the > >>> recording of the ISNI and other appropriate standard identifiers > >>> in the bibliographic format (see new definition: > >>> http://www.loc.gov/marc/bibliographic/ecbdcntf.html) > >>> > >>> In the authority format, the ISNI is recorded in the 024. Subfield > $0 > >>> is not defined in the authority format in the 1XXs as (somebody > >>> mentioned this in this thread) the authority record control number > or > >>> identifier would be associated to the preferred heading. Field 024 > is > >>> the appropriate place to record identifiers associated with the > >>> entity represented by the whole authority record. However the > >>> definition of subfield $0 in the authority format (i.e. 5XXs) was > >>> extended in a similar way to the bibliographic format to enable > >>> the recording of identifiers of related entities. > >>> (http://www.loc.gov/marc/authority/ecadcntf.html) > >>> > >>> So on a similar basis, you could record URIs in MARC authority > >>> records as in the example below: > >>> > >>> 024 7# $a8462832856536435$2isni > >>> 024 7# $ahttp://www.viaf.org/viaf/120719476/$2uri > >>> 024 7# $ahttp://openlibrary.org/authors/OL22672/A$2uri > >>> 100 1# $aRendell, Ruth,$d1930- > >>> 500 1# $aVine, > >>> > Barbara,$d1930$0(isni)1422458635730476$0(uri)http://www.viaf.org/viaf > >>> /9 8146313/$0(uri)http://openlibrary.org/authors/OL21420A/ > >>> 670 ## $aHer From Doon with death, 1964. > >>> 670 ## $aHer A dark-adapted eye, 1986:$bCIP t.p. (Barbara Vine) > >>> 670 ## $aInfo. from pub., 1/28/86$b(Barbara Vine is pseud. used by > >>> Ruth > >>> Rendell) > >>> > >>> uri is already defined in the Standard Identifier Source Codes > >>> list > >>> http://www.loc.gov/standards/sourcelist/standard-identifier.html > >>> > >>> Subfield $0 is also defined in the 7XXs in the authority format, > >>> which would allow the multilingual linking Xavier mentions below. > >>> > >>> Corine > >>> > >>> > >>> ********************************* > >>> Corine Deliot > >>> Metadata Standards Analyst > >>> The British Library > >>> Boston Spa, Wetherby > >>> West Yorkshire LS23 7BQ > >>> e-mail: corine.deliot@bl.uk > >>> ********************************* > >>> > >>> -----Original Message----- > >>> From: public-lld-request@w3.org [mailto:public-lld-request@w3.org] > On > >>> Behalf Of Xavier Agenjo > >>> Sent: 2010-10-02 16:53 > >>> To: Karen Coyle; Young,Jeff (OR) > >>> Cc: public-lld > >>> Subject: RE: Linked Data URIs in MARC Authorities > >>> > >>> Dear all, > >>> > >>> At the Biblioteca Virtual de Poligrafos (Polimath Virtual > >>> Library), we have used, for the moment, 670 (Source Data Found (R) > >>> $u in authority records for VIAF and LCSH URIs > >>> > >>> 670 > >>> $aVIAF$bID:89794074$uhttp://www.viaf.org/viaf/89794074/ > >>> > >>> 670 $aLibrary of Congress Subject > >>> Headings$uhttp://id.loc.gov/authorities/sh85090244#concept > >>> > >>> We tried not to create a new field or subfield that always causes > >>> problems of understanding as we want to continue sharing > >>> bibliographic data in a standardized way. Also, we considered 856 > too > >>> generic to be used to built further applications or navigation > >>> methods through persons, concepts, etc. > >>> Probably, the best solution is 1XX $0 in authority headings, as it > >>> can be used for headings + subdivision or subdivision and $0 it is > >>> not for human reading. > >>> However, the advantage of using the $0 in the 1XX is that it > >>> allows links between people and concepts in a multilingual way. > >>> Something like that: > >>> > >>> 150 $0FILA20100020647 $aIndulgencias (Derecho > canónico) > >>> 750 > >>> $0(LCSH)http://id.loc.gov/authorities/sh85065814#concept $aThe > >>> Library of Congress. Authorities & Vocabularies. LC Subject > Headings > >>> > >>> Of course, something is missing in 1XX $0 that is the possibility > to > >>> express the language of heading (but that happens in all the other > >>> solutions proposed) > >>> > >>> If you want to see more, including the use of MARC/RDA fields in > >>> authority records you can take a look to > >>> > http://www.larramendi.es/i18n/consulta_aut/registro.cmd?control=POLI2 > >>> 00 90012677&formato=etiquetado_aut&aplicar=Aplicar or to the > >>> > >>> Xavier > >>> > >>> Xavier Agenjo > >>> Project Manager > >>> Fundacion Ignacio Larramendi > >>> http://www.larramendi.es > >>> > >>> ________________________________________ > >>> De: public-lld-request@w3.org [public-lld-request@w3.org] En > >>> nombre de Karen Coyle [kcoyle@kcoyle.net] Enviado el: sábado, 02 > >>> de > octubre > >>> de 2010 0:20 > >>> Para: Young,Jeff (OR) > >>> CC: public-lld > >>> Asunto: RE: Linked Data URIs in MARC Authorities > >>> > >>> Quoting "Young,Jeff (OR)" <jyoung@oclc.org>: > >>> > >>> > >>> > > >>> > 024 8# $u http://example.org/foo > >>> > > >>> > I would argue that the spec for this new $u should be explicitly > >>> > worded to mention "Linked Data". Sensible behavior would be for > it > >>> > to lead to content-negotiatable representations in HTML, > >>> > MARCXML, MADS, RDF, etc. > >>> > >>> But isn't the identifier *just* an identifier? It could be used > >>> for anything where an identifier is useful -- not just linked > >>> data. Or are you thinking of this subfield to be *only* for LD identifiers? > In > >>> that case, it might be useful to use a subfield other than $u, > which > >>> in MARC has usually been used for URLs, not URIs (the 856 is > >>> specifically a location area field). So 035 $l or 035 $i, or > >>> something like that. > >>> > >>> kc > >>> > >>> > > >>> > Jeff > >>> > > >>> >> -----Original Message----- > >>> >> From: rxs@talisplatform.com [mailto:rxs@talisplatform.com] On > >>> >> Behalf Of Ross Singer > >>> >> Sent: Friday, October 01, 2010 4:36 PM > >>> >> To: Martin Malmsten > >>> >> Cc: Young,Jeff (OR); public-lld > >>> >> Subject: Re: Linked Data URIs in MARC Authorities > >>> >> > >>> >> Martin, I think it's a fine proposal. > >>> >> > >>> >> The only possible downside I can see (as opposed to using, say, > >>> >> the 035, for example) is that it would be in a different > location > >>> >> depending on the kind of authority record it is > >>> >> (personal/corporate/meeting name, uniform title, topical, > >>> >> geographical, etc.). > >>> >> > >>> >> That's not necessarily a killer, but it would mean you'd need > >>> >> to > >>> look > >>> >> for every field until you found the URI. Using the 035 would > >>> >> centralize that a bit. > >>> >> > >>> >> Martin, since $0 isn't actually considered part of MARC > authority, > >>> >> have you seen any systems reject this (or have you just used it > >>> >> locally)? > >>> >> > >>> >> My guess is that systems will ignore the subfields they don't > >>> >> understand rather than raise an error, but I guess it will take > a > >>> >> real world trial to know for sure. > >>> >> > >>> >> -Ross. > >>> >> > >>> >> On Fri, Oct 1, 2010 at 4:29 PM, Martin Malmsten > >>> >> <Martin.Malmsten@kb.se> > >>> >> wrote: > >>> >> > Jeff, Ross, > >>> >> > > >>> >> > we use $0 when exporting our bibliographic[1] records which > >>> >> > is why I > >>> >> chose it. Again this is just testing, but it seems a likely > >>> candidate. > >>> >> > > >>> >> >> It seems applicable, but the context it would be used in > would > >>> >> >> sort > >>> >> of > >>> >> >> imply the opposite meaning than what it does in > >>> >> >> bibliographic > >>> >> records. > >>> >> > I see the link as going either "sideways" to another > >>> >> > authority > >>> >> record/page/resource or "upwards", e.g from our 750 to a LCSH. > In > >>> the > >>> >> latter case we would ultimately want to propagate changes made > to > >>> the > >>> >> LCSH into our record, making the link behave like between a bib > >>> >> and an auth. > >>> >> > > >>> >> > /martin > >>> >> > > >>> >> > On Oct 1, 2010, at 9:53 PM, Ross Singer wrote: > >>> >> > > >>> >> >> Jeff, > >>> >> >> > >>> >> >> The 1xx$0 is actually used in bib records (not authority) > >>> >> >> and is > >>> >> defined as: > >>> >> >> $0 - Authority record control number (R) > >>> >> >> > >>> >> >> http://www.loc.gov/marc/bibliographic/bd100.html > >>> >> >> > >>> >> >> It seems applicable, but the context it would be used in > would > >>> >> >> sort > >>> >> of > >>> >> >> imply the opposite meaning than what it does in > >>> >> >> bibliographic > >>> >> records. > >>> >> >> > >>> >> >> -Ross. > >>> >> >> > >>> >> >> On Fri, Oct 1, 2010 at 3:47 PM, Young,Jeff (OR) > >>> >> >> <jyoung@oclc.org> > >>> >> wrote: > >>> >> >>> Martin, > >>> >> >>> > >>> >> >>> I can believe that "the 1XX identifies what the record is > >>> *about*" > >>> >> and would challenge anyone to argue otherwise. > >>> >> >>> > >>> >> >>> What is your argument for choosing $0 rather than $u? > Neither > >>> are > >>> >> currently specified and $u appears to be commonly used for URIs > in > >>> >> other fields: > >>> >> >>> > >>> >> >>> http://www.loc.gov/marc/856guide.html#other_fields > >>> >> >>> > >>> >> >>> Jeff > >>> >> >>> > >>> >> >>>> -----Original Message----- > >>> >> >>>> From: Martin Malmsten [mailto:Martin.Malmsten@kb.se] > >>> >> >>>> Sent: Friday, October 01, 2010 3:32 PM > >>> >> >>>> To: Young,Jeff (OR) > >>> >> >>>> Cc: public-lld@w3.org > >>> >> >>>> Subject: Re: Linked Data URIs in MARC Authorities > >>> >> >>>> > >>> >> >>>> Jeff, > >>> >> >>>> > >>> >> >>>> I understand, but would not putting a $0 in the 1XX > >>> >> >>>> accomplish > >>> >> just > >>> >> >>>> that since the 1XX identifies what the record is "about"? > I'm > >>> >> >>>> just saying that by using $0 you could link to other > >>> >> >>>> things (or > >>> >> >>>> Things) > >>> >> from > >>> >> >>>> other parts of the record as well. > >>> >> >>>> > >>> >> >>>> However, we do actually use 856 with a $z in our > >>> >> >>>> production > >>> >> environment > >>> >> >>>> today. It works, but I do not like the amount of implicit > >>> >> information > >>> >> >>>> with this (or rather our version of this) solution. > >>> >> >>>> > >>> >> >>>> Example: > >>> >> >>>> 100 '1' ' ' $aStrindberg, August, $d1849-1912 > >>> >> >>>> 856 '4' '8' $uhttp://viaf.org/viaf/54154627 $zVIAF > >>> >> >>>> > >>> >> >>>> /martin > >>> >> >>>> > >>> >> >>>> On Oct 1, 2010, at 8:54 PM, Young,Jeff (OR) wrote: > >>> >> >>>> > >>> >> >>>>> Martin, > >>> >> >>>>> > >>> >> >>>>> I think our use cases are getting mixed up. I want a > >>> >> >>>>> place to > >>> >> >>>> identify the thing the Authority record (as a whole) > >>> represents. > >>> >> >>>> Linking to *other* things inside a MARC record is a harder > >>> >> >>>> and > >>> >> more > >>> >> >>>> controversial problem as Michael's response indicates. I'm > >>> >> >>>> hoping > >>> >> this > >>> >> >>>> is low-hanging fruit, but I admit the difference is subtle. > >>> >> >>>>> > >>> >> >>>>> Jeff > >>> >> >>>>> > >>> >> >>>>>> -----Original Message----- > >>> >> >>>>>> From: Martin Malmsten [mailto:Martin.Malmsten@kb.se] > >>> >> >>>>>> Sent: Friday, October 01, 2010 2:36 PM > >>> >> >>>>>> To: Young,Jeff (OR) > >>> >> >>>>>> Cc: public-lld@w3.org > >>> >> >>>>>> Subject: Re: Linked Data URIs in MARC Authorities > >>> >> >>>>>> > >>> >> >>>>>> Jeff, Karen. > >>> >> >>>>>> > >>> >> >>>>>> I prefer a subfield over a field because may I want to > link > >>> >> >>>>>> only > >>> >> >>>> parts > >>> >> >>>>>> of the record, and not necessarily the 1XX-field, to > >>> >> >>>>>> another > >>> >> >>>> resource > >>> >> >>>>>> without having to resort to a $8-link (*shudder*). > >>> >> >>>>>> > >>> >> >>>>>> Example: > >>> >> >>>>>> 150 ' ' ' ' $aMödrar > >>> >> >>>>>> 750 ' ' '0' $aMothers $0 > >>> >> >>>>>> http://id.loc.gov/authorities/sh85087526#concept > >>> >> >>>>>> > >>> >> >>>>>> /martin > >>> >> >>>>>> > >>> >> >>>>>> On Oct 1, 2010, at 6:46 PM, Young,Jeff (OR) wrote: > >>> >> >>>>>> > >>> >> >>>>>>> How about this: > >>> >> >>>>>>> > >>> >> >>>>>>> 856 4# $u http://example.org/foo > >>> >> >>>>>>> > >>> >> >>>>>>> Here's the documentation for the field: > >>> >> >>>>>>> > >>> >> >>>>>>> http://www.loc.gov/marc/authority/ad856.html > >>> >> >>>>>>> http://www.loc.gov/marc/856guide.html > >>> >> >>>>>>> > >>> >> >>>>>>> Jeff > >>> >> >>>>>>> > >>> >> >>>>>>> From: Martin Malmsten [mailto:Martin.Malmsten@kb.se] > >>> >> >>>>>>> Sent: Friday, October 01, 2010 12:26 PM > >>> >> >>>>>>> To: Young,Jeff (OR) > >>> >> >>>>>>> Cc: public-lld@w3.org > >>> >> >>>>>>> Subject: Re: Linked Data URIs in MARC Authorities > >>> >> >>>>>>> > >>> >> >>>>>>> I'm considering/testing $0 in the 1XX fields, analogues > to > >>> $0 > >>> >> in > >>> >> >>>> the > >>> >> >>>>>> bib record. The idea is that a DbPedia/Freebase/VIAF URI > >>> could > >>> >> >>>>>> authorise an authority record. "Global headings change" > >>> >> >>>>>> becomes > >>> >> a > >>> >> >>>> fun > >>> >> >>>>>> challenge with LD URIs within the record :) > >>> >> >>>>>>> > >>> >> >>>>>>> Sent from my iPhone > >>> >> >>>>>>> > >>> >> >>>>>>> On 1 okt 2010, at 18:00, "Young,Jeff (OR)" > >>> >> >>>>>>> <jyoung@oclc.org> > >>> >> wrote: > >>> >> >>>>>>> > >>> >> >>>>>>> If somebody wanted to put a Linked Data RWO URI in a > MARC > >>> >> Authority > >>> >> >>>>>> record, where would it plausibly go? > >>> >> >>>>>>> > >>> >> >>>>>>> Jeff > >>> >> >>>>>>> > >>> >> >>>>>>> --- > >>> >> >>>>>>> Jeffrey A. Young > >>> >> >>>>>>> Software Architect > >>> >> >>>>>>> OCLC Research, Mail Code 410 OCLC Online Computer > Library > >>> >> >>>>>>> Center, Inc. > >>> >> >>>>>>> 6565 Kilgour Place > >>> >> >>>>>>> Dublin, OH 43017-3395 > >>> >> >>>>>>> www.oclc.org > >>> >> >>>>>>> > >>> >> >>>>>>> Voice: 614-764-4342 > >>> >> >>>>>>> Voice: 800-848-5878, ext. 4342 > >>> >> >>>>>>> Fax: 614-718-7477 > >>> >> >>>>>>> Email: jyoung@oclc.org > >>> >> >>>>>>> > >>> >> >>>>>> > >>> >> >>>>>> -------------------------------------------------------- > >>> >> >>>>>> - > -- > >>> >> >>>>>> -- > >>> - > >>> >> >>>>>> -- > >>> >> - > >>> >> >>>>>> Martin Malmsten (martin.malmsten@kb.se) - Senior > Developer > >>> >> >>>>>> National Library of Sweden / National cooperation dept. > >>> >> >>>>>> / LIBRIS http://libris.kb.se > >>> >> >>>>>> > >>> >> >>>>>> > >>> >> >>>>> > >>> >> >>>>> > >>> >> >>>> > >>> >> >>>> ---------------------------------------------------------- > >>> >> >>>> - > -- > >>> >> >>>> -- > >>> - > >>> >> >>>> - Martin Malmsten (martin.malmsten@kb.se) - Senior > Developer > >>> >> >>>> National Library of Sweden / National cooperation dept. / > >>> LIBRIS > >>> >> >>>> http://libris.kb.se > >>> >> >>>> > >>> >> >>>> > >>> >> >>> > >>> >> >>> > >>> >> >>> > >>> >> >>> > >>> >> >>> Please consider the environment before printing this email. > >>> >> >>> > >>> >> >>> Find out more about Talis at http://www.talis.com/ shared > >>> >> >>> innovation(tm) > >>> >> >>> > >>> >> >>> Any views or personal opinions expressed within this email > may > >>> >> >>> not > >>> >> be those of Talis Information Ltd or its employees. The content > of > >>> >> this email message and any files that may be attached are > >>> >> confidential, and for the usage of the intended recipient only. > If > >>> >> you are not the intended recipient, then please return this > >>> >> message to the sender and delete it. Any use of this e-mail by > an > >>> >> unauthorised recipient is prohibited. > >>> >> >>> > >>> >> >>> Talis Information Ltd is a member of the Talis Group of > >>> companies > >>> >> and is registered in England No 3638278 with its registered > office > >>> at > >>> >> Knights Court, Solihull Parkway, Birmingham Business Park, B37 > 7YB. > >>> >> >>> > >>> >> > > >>> >> > ------------------------------------------------------------- > >>> >> > - > -- > >>> >> > - Martin Malmsten (martin.malmsten@kb.se) - Senior Developer > >>> National > >>> >> > Library of Sweden / National cooperation dept. / LIBRIS > >>> >> > http://libris.kb.se > >>> >> > > >>> >> > > >>> >> > > >>> > > >>> > > >>> > > >>> > > >>> > >>> > >>> > >>> -- > >>> Karen Coyle > >>> kcoyle@kcoyle.net http://kcoyle.net > >>> ph: 1-510-540-7596 > >>> m: 1-510-435-8234 > >>> skype: kcoylenet > >>> > >>> > >>> > >>> > >>> > >>> > ********************************************************************* > >>> ** > >>> *** > >>> > >>> Help us celebrate National Customer Service Week 4 - 10 October. > >>> National Customer Service Week is designed to raise the awareness > of > >>> customer service and the vital role it plays within any > organisation. > >>> It is also an opportunity to say a big thank you to all our > customers > >>> for their support. > >>> We are having an Open Day at our site in Yorkshire on Tuesday 5th > >>> October. If you are interested in seeing 'behind the scenes' of > >>> one of the largest and most technologically advanced library > repositories > >>> in the world, follow an order from receipt to delivery and meet > >>> the Customer Service team, please contact us at mailto:customer- > >>> services@bl.uk > >>> > >>> Experience the British Library online at http://www.bl.uk/ > >>> > >>> The British Library’s new interactive Annual Report and Accounts > >>> 2009/10 : http://www.bl.uk/knowledge > >>> > >>> Help the British Library conserve the world's knowledge. Adopt a > Book. > >>> http://www.bl.uk/adoptabook > >>> > >>> The Library's St Pancras site is WiFi - enabled > >>> > >>> > ********************************************************************* > >>> ** > >>> ** > >>> > >>> The information contained in this e-mail is confidential and may > >>> be legally privileged. It is intended for the addressee(s) only. > >>> If > you > >>> are not the intended recipient, please delete this e-mail and > notify > >>> the mailto:postmaster@bl.uk : The contents of this e-mail must not > be > >>> disclosed or copied without the sender's consent. > >>> > >>> The statements and opinions expressed in this message are those of > >>> the author and do not necessarily reflect those of the British > >>> Library. The British Library does not take any responsibility for > the > >>> views of the author. > >>> > >>> > ********************************************************************* > >>> ** > >>> ** > >>> Think before you print > >> > >> > > > > > > > > -- > > Karen Coyle > > kcoyle@kcoyle.net http://kcoyle.net > > ph: 1-510-540-7596 > > m: 1-510-435-8234 > > skype: kcoylenet > > > > > > > > > > -- > Karen Coyle > kcoyle@kcoyle.net http://kcoyle.net > ph: 1-510-540-7596 > m: 1-510-435-8234 > skype: kcoylenet > >
Received on Tuesday, 14 December 2010 23:00:28 UTC