Maybe I'm not understanding the value of turning strings into resources. It would help to have that explained in relation to a different sort of example."Hamlet" is the preferred title of two different works--a play by Shakespeare and a novel by Faulkner. What is the value of having "Hamlet" per se coded as a resource? What defines that resource, beyond its form as a word? What functionality does the resource have that a string would not have?I'm all for using resources over strings when there is a resource I can reference or create, and the resource offers me something more than a string; but if the resource has no specific significance, I'm not sure what that "something more" would be.(By "artisanal" I meant cataloging done with skilled, careful attention to each object--a luxury we can afford for only a portion of our workflow nowadays)StephenOn Fri, May 15, 2015 at 8:49 AM, Cindy Wolff <[log in to unmask]> wrote:
What is meant by “artisanal” cataloging?
From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Stephen Hearn
Sent: Thursday, May 14, 2015 6:47 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] RDF dual properties... can be a cataloging question
Expanding on Karen's point, cataloging rules have long supported and continue to allow the MARC 245 $a to represent both the title transcription from the manifestation and the SOMETIMES preferred title of the work contained in the manifestation. The latter possibility is much more interesting from a resource management standpoint, since it offers us the chance to correlate work entities; but it's very hard to determine whether or not it's the case for a particular 245 $a.
In other words, in MARC data there may be two things being described simultaneously--a work and a manifestation. The 245 $a sometimes carries a single string which is differently defined as separate properties for each thing. Nothing in the MARC coding reliably says whether the string represents both these property values or only one.
I agree with Rob Sanderson that the decision whether this sort of coding ambiguity should continue belongs to BIBFRAME, not to implementers. But the practicalities of library data will dictate that sometimes, literal strings with little or no distinct entity assertion is the best we can expect. Legacy data has already been noted. Most of the new catalog data we load now comes from batch loading, much of it from non-library sources, done with little chance for artisanal cataloger review. And then there the everyday pressures of too little staff with too much to process.
I'd prefer an encoding which doesn't overestimate the value of a string, because there will be many strings in our catalogs in which we've invested very little.
On Thu, May 14, 2015 at 4:36 PM, Robert Sanderson <[log in to unmask]> wrote:
On Thu, May 14, 2015 at 1:25 PM, Karen Coyle <[log in to unmask]> wrote:
On 5/14/15 9:21 AM, Owen Stephens wrote:
I don’t see a problem with allowing string properties when there is no question of there being a resource - but that’s a decision BIBFRAME should make, not the implementors. The problem I have is with letting the implementor/data dictate whether you have a string or a resource (or a date etc.) in any particular instance.
Turning titles (MARC 245) and other areas of bibliographic description into resources is not a slam-dunk, IMO. If we go with Rob's "all objects are resources" are we saying that a title is semantically as much of a resource as a creator? Will our data reflect the difference between a string as resource and a rwo as resource? Does that matter?
If there are two properties of the same "thing" (like title and subtitle) then clearly there is a thing that has those properties, not just a single string. Perhaps I'm being naive but it doesn't seem very complex :)
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305