RE: MARC Authority 001 and Linked Data (was RE: Linked Data URIs in MARC Authorities)

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

Received on Wednesday, 15 December 2010 09:04:14 UTC