- From: Young,Jeff (OR) <jyoung@oclc.org>
- Date: Tue, 14 Dec 2010 17:03:40 -0500
- To: "Karen Coyle" <kcoyle@kcoyle.net>, "public-lld" <public-lld@w3.org>
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 22:05:07 UTC