W3C home > Mailing lists > Public > public-xg-lld@w3.org > August 2010

RE: is FRBR relevant?

From: Young,Jeff (OR) <jyoung@oclc.org>
Date: Mon, 9 Aug 2010 14:58:45 -0400
Message-ID: <52E301F960B30049ADEFBCCF1CCAEF5909429729@OAEXCH4SERVER.oa.oclc.org>
To: "Karen Coyle" <kcoyle@kcoyle.net>, <public-xg-lld@w3.org>
Strictly speaking, these system could continue to store (cache) the
display form in the bibliographic record if they somehow stored the
identifier in close proximity (e.g.
http://id.loc.gov/authorities/sh85148273#concept). Having a plausible
place in MARC to store these identifiers would help. They could then
bulk download the LCSH RDF (http://id.loc.gov/download/) and
systematically replace all the display forms periodically based on that
identifier.

http://id.loc.gov/authorities/sh85148273#concept a skos:Concept ;
	skos:prefLabel "World War, 1939-1945" .

Like Karen, I assume this requires more control and vigilance over
individual fields than most systems can handle.

Jeff

Karen Coyle write:
> Yes, it's ugly. Using identifiers would help with some of this, but
> only if we stopped storing the display forms in the bibliographic
> record. We also need to be able to update individual fields -- MARC is
> designed to take a full record replace, and I don't know if there are
> many systems that can update individual fields.
> 
> kc
> 
> 
> 
> 
> >
> > I'm just guessing but I would think that they
> > would add headings from time to time but they
> > would rarely if ever delete or change an existing
> > one. Although I could be very wrong...
> >
> > Cheers,
> > -w
> >
> > --
> > William Waites           <william.waites@okfn.org>
> > Mob: +44 789 798 9965    Open Knowledge Foundation
> > Fax: +44 131 464 4948                Edinburgh, UK
> >
> > RDF Indexing, Clustering and Inferencing in Python
> > 		http://ordf.org/
> >
> >
> 
> 
> 
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> ph: 1-510-540-7596
> m: 1-510-435-8234
> skype: kcoylenet
> 
> 
Received on Monday, 9 August 2010 18:59:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 9 August 2010 18:59:16 GMT