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.
> ...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.
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
|