Print

Print


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