LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


BIBFRAME@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

BIBFRAME Home

BIBFRAME Home

BIBFRAME  August 2014

BIBFRAME August 2014

Subject:

Re: Proposal to handle "Providers" differently

From:

"Svensson, Lars" <[log in to unmask]>

Reply-To:

Bibliographic Framework Transition Initiative Forum <[log in to unmask]>

Date:

Thu, 14 Aug 2014 17:46:13 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (296 lines)

All,

I'm arriving late to this party but hopefully not too late to throw in my 2 öre...

When we talk about using URIs to identify places, we need to be careful what kind of places we talk about. If we want to specify that a publication is about a specific place (e. g. a guide book to London (Ontario)), a URI for London (Ontario) is perfectly fine.

If we -- however -- talk about place names in publication statements, URIs (or geographic coordinates) may or may not be useful. For a C17 publication with the (fictive) publication statement "published by John Nicholson in the High Street at the sign of the lantern and printed by Jeremiah McTavish in the Lower Mile" it is clear that the two places mentioned are the locations where the publication (preparation of manuscript etc.) and the printing took place. We can replace those two with URIs or geographic coordinates.

Publication statements by modern scientific publishers sometimes mention a whole range of place names, as in "Heidelberg, Berlin, New York, Tokyo, München: Very-Big-Scientific-Publisher, 2012". I'm still not sure if this means that 

1) the book was published in all those places (at the same time?), or if it means that
2) it was published by the Very-Big-Scientific-Publisher and that the publisher has offices in all those places.

My gut feeling is that it really means 2) and that we really cannot say that the book was published in http://dbpedia.org/data/Berlin, http://dbpedia.org/data/Tokyo or any of the other places. Please feel free to prove me wrong.

Best,

Lars

*** Lesen. Hören. Wissen. Deutsche Nationalbibliothek *** 
-- 
Dr. Lars G. Svensson
Deutsche Nationalbibliothek
Informationstechnologie
Telefon: +49-69-1525-1752
mailto:[log in to unmask] 
http://www.dnb.de


> -----Original Message-----
> From: Bibliographic Framework Transition Initiative Forum
> [mailto:[log in to unmask]] On Behalf Of Donald R. Thornbury
> Sent: Friday, August 01, 2014 5:26 PM
> To: [log in to unmask]
> Subject: Re: [BIBFRAME] Proposal to handle "Providers" differently
> 
> I'm the cataloger Tim mentioned who observed that RDA is "way too string-
> y" and mentioned co-evolution of content standards and data models.
> Provider/264 represents a clear scenario.  Transcription as in RDA is a relative
> latecomer.  Earlier cataoging rules provided for all kinds of brief forms, or
> none at all when the publisher was also the main entry.  In spirit, the earlier
> rules were pretty much using a "preferred form" of the publisher's name.
> There was no evidence that users were impeded in their understanding of
> the data they found on catalog cards or in MARC records with such content.
> The chief purpose of our descriptive data is to connect users with resources.
> Providing a stylized picture of sources of information isn't really important
> with regard to publication (etc.).  In my view Find, Identify, and Select would
> be perfectly well served by forgetting about transcription altogether and
> relying on cataloger-formulated representation of entities.  Concern about
> documenting usage or providing an exact version of source data can be
> handled in other ways, if necessary.
> By the way, I mean this to apply to early printed resources as well.  The
> current string "Printed and sold by William Darton, Jun., 58, Holborn Hill"
> would be replaced with the URI and predicate representing what is now 700
> Darton, William, 1781-1854, publisher. The address would be 371a in the
> "authority record."
> 
> --Don
> 
> Donald R. Thornbury
> Head, Technical Services for Special Collections
> Department of Rare Books and Special Collections
> Princeton University Library
> One Washington Road
> Princeton, NJ 08544-2098
> Office: 609.258.0874
> Fax: 609.258.2324
> 
> 
> 
> -----Original Message-----
> From: Bibliographic Framework Transition Initiative Forum
> [mailto:[log in to unmask]] On Behalf Of Ford, Kevin
> Sent: Friday, August 01, 2014 10:33 AM
> To: [log in to unmask]
> Subject: Re: [BIBFRAME] Proposal to handle "Providers" differently
> 
> Comments in-line.
> 
> > -----Original Message-----
> > From: Bibliographic Framework Transition Initiative Forum
> > [mailto:[log in to unmask]] On Behalf Of Joseph Montibello
> > Sent: Thursday, July 31, 2014 8:43 PM
> > To: [log in to unmask]
> > Subject: Re: [BIBFRAME] Proposal to handle "Providers" differently
> >
> > Hi,
> >
> > Not a cataloger here, but this is an interesting conversation. I just
> > want to call one piece out:
> >
> > > ...help a user match that which he/she may hold with what is seen in
> > > the record
> >
> >
> > While I know that's the reason for the current practice, that's not a
> > compelling reason to insist that bibframe (or any future system) must
> > do also support that use case.
> 
> The actual use case is "support RDA cataloging."  The transcription aspect,
> which pertains to the above, is a byproduct of meeting that use case.
> 
> >
> > > ...it would no longer match what is on the manifestation.
> >
> > Are we trading the certainty of matching this string against the
> > (assumed) physical item:
> > >>>>> Chicago : University of Chicago Press, 1955.
> >
> > vs. a different sort of certainty that might be found in linked data like this:
> > publishedAt: http://dbpedia.org/page/Chicago
> > publishedBy: http://fr.dbpedia.org/page/University_of_chicago_press
> > publishedIn: http://dbpedia.org/page/1955
> >
> > If we have to give up one of these, I'd vote for ditching the old
> > practice of matching item in hand to get the benefits of linked data.
> 
> The proposal is actually to accommodate /both/ of those.  The
> publicationStatement would allow a cataloger to record the information "as
> found on the source" while the other properties would provide a more
> structured, linky approach.
> 
> All the best,
> Kevin
> 
> 
> >
> > Just my {valueOfOpinion:http://dbpedia.org/page/Two-
> > cent_piece_%28United_States_coin%29}.
> > Joe Montibello, MLIS
> > Library Systems Manager
> > Dartmouth College
> > 603.646.9394
> > [log in to unmask]
> >
> >
> >
> > On Jul 31, 2014, at 6:06 PM, Ford, Kevin <[log in to unmask]> wrote:
> >
> > > Comments in-line.
> > >
> > >> -----Original Message-----
> > >> From: Bibliographic Framework Transition Initiative Forum
> > >> [mailto:[log in to unmask]] On Behalf Of Robert Sanderson
> > >> Sent: Thursday, July 31, 2014 5:30 PM
> > >> To: [log in to unmask]
> > >> Subject: Re: [BIBFRAME] Proposal to handle "Providers" differently
> > >>
> > >>
> > >> +1 to standardizing the representation of place, using identifiers.
> > >> +(I'm sure that's no surprise to any one)
> > >>
> > >> I'm less in favor of publisherStatement to transcribe and then
> > >> repeat the same information in somewhat of a jumbled fashion with
> > >> repeating publishedAt/By/On.  If there's the possibility of
> > >> multiples, as demonstrated, then the information shouldn't get lost
> > >> as to which place is associated with which organization, IMO.
> > >
> > > I'm not a fan of the repetition either, but RDA often requires
> > /transcription/ with all the pitfalls that might entail (misspellings,
> > non- standard abbreviations, non-standard spellings) and so I worry
> > about the need to record those details "as they appear on the source of
> information"
> > and the impact that would have trying to standardize on bf:Organizations
> and
> > bf:Places.   Functionally, the transcription serves to help a user match that
> > which he/she may hold with what is seen in the record, which is why
> > standardizing abbreviations (Chicago, Ill. becomes Chicago, IL
> > perhaps), for example, can be a problem, since it would no longer
> > match what is on the manifestation.
> > >
> > > I also have fantasies that - down the road apiece - a cataloger
> > > would be
> > able to type in a publicationStatement into a text field, at which
> > point background programming would perform some kind of entity
> > recognition and populate the proposed fields without the cataloger
> > having to do double the work.  That doesn't get around the inherent
> > duplication of data, but it mitigates the effort that produced it.
> > >
> > >>
> > >> Here the structure isn't imposed just for the sake of having
> > >> structure, it's to model the publication event and its participants.
> > >> The W3C PROV-O equivalent would be:
> > >>
> > >> _:instance1 a bf:Instance, prov:Entity ;
> > >>     prov:wasGeneratedBy [ _:publicationEvent a prov:Activity,
> > >> bf:PublicationActivity ;
> > >>         prov:used [ _:work1 a bf:Work ] ;    // maybe?
> > >>         prov:wasAssociatedWith [ _:ucp a bf:Organization ; ...] ;
> > >>         prov:wasAssociatedWith [ _:gv a bf:Organization ; ... ] ;
> > >>         prov:startedAtTime "1955" ;
> > >>     ]
> > >> ]
> > >>
> > >
> > > This seems complicated (more so, in fact) and returns us, more or
> > > less, back
> > to where it is now, which is to say a mostly non-reusable resource.
> > Also, those two wasAssociatedWiths would have to remain in the order
> > in which they appeared on the source.  You can appreciate the headache
> > that introduces in RDF-land.
> > >
> > > I liked your earlier question to Karen about what it all meant.  Are
> > > the
> > publishers (in two different locations) working together to produce
> > the /same thing/ or are we looking at two manifestations, each
> > published by one of the indicated publishers in that particular year.
> > The latter would make things a lot easier, as you noted, and it is how
> > we've interpreted that construct, but the documentation is vague on this
> point.
> > >
> > > Warmly,
> > > Kevin
> > >
> > >
> > >>
> > >> Rob
> > >>
> > >>
> > >> On Thu, Jul 31, 2014 at 2:04 PM, Ford, Kevin <[log in to unmask]> wrote:
> > >> Agreed.
> > >>
> > >> The transcription element aside, which would be contained within
> > >> the publisherStatement, I would expect a value vocabulary be used,
> > >> and therefore an identifier be used, when recording the place of
> > >> publication /as data/.  In that case, the identifier would be
> > >> specific to Paris, France versus Paris, Texas.
> > >>
> > >> Yours,
> > >> Kevin
> > >>
> > >>
> > >>> -----Original Message-----
> > >>> From: Bibliographic Framework Transition Initiative Forum
> > >>> [mailto:[log in to unmask]] On Behalf Of
> [log in to unmask]
> > >>> Sent: Thursday, July 31, 2014 4:49 PM
> > >>> To: [log in to unmask]
> > >>> Subject: Re: [BIBFRAME] Proposal to handle "Providers" differently
> > >>>
> > >>> This seems to me to be a really excellent opportunity to take
> > >>> advantage of the opportunity presented by Linked Data. We could
> > >>> translate: "Paris [France]" to http://dbpedia.org/data/Paris or
> > >>> some other specific choice,  or "Chicago [Illinois]" to
> > >>> http://sws.geonames.org/4887398 or some other specific choice...
> > >>> we could use identifiers for a task for which they are very well suited:
> > >> disambiguation.
> > >>>
> > >>> ---
> > >>> A. Soroka
> > >>> The University of Virginia Library
> > >>>
> > >>> On Jul 31, 2014, at 4:09 PM, "J. McRee Elrod" <[log in to unmask]> wrote:
> > >>>
> > >>>> Karen posted:
> > >>>>
> > >>>>> e.g. Paris : Gauthier-Villars; Chicago : University of Chicago Press,
> 1955.
> > >>>>
> > >>>> As I keep saying, our European and/or Asian clients would want
> > >>>> [France] after Paris, and [Illinois] after Chicago.  Our North
> > >>>> American cleints want jurisdction for some cities for which
> > >>>> Australian and DLC records lack jurisdiction.  A city known in
> > >>>> Canberra or the Beltway may not be known in Canada.  Isn't it
> > >>>> time, since we are no longer limited by what we can get on a
> > >>>> card, to leave our
> > >> Anglo silo?
> > >>>>
> > >>>> It seems to me, the move to Bibframe would be a time to
> > >>>> standardize representation of place.
> > >>>>
> > >>>> As was said in the early days of automation, "garbage in, garbage
> > >>>> out".  Isn't it time we were more consistent in what we are
> > >>>> coding, as opposed to feeding in truncated unit card type data?
> > >>>>
> > >>>> In Bibframe, the labels are sometimes longer than the data being
> > >>>> coded!
> > >>>>
> > >>>>
> > >>>>   __       __   J. McRee (Mac) Elrod ([log in to unmask])
> > >>>>  {__  |   /     Special Libraries Cataloguing
> > >>>> HTTP://www.slc.bc.ca/
> > >>>>  ___} |__
> > >>>
> > >>
> >
> \__________________________________________________________
> > >>
> > >>
> > >>
> > >>
> > >> --
> > >> Rob Sanderson
> > >> Technology Collaboration Facilitator Digital Library Systems and
> > >> Services Stanford, CA 94305

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
July 2011
June 2011

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager