I think it's easier to see the benefits when you take away the title resource and are left with just a string.

Without the resource:

* You can't have parts of titles, e.g. no subtitle as it's just a single string ; or you you can have parts, but can't have multiple titles.
   -- e.g. you could have work title X ; subtitle Y but not work title X,X2 ; subtitle Y as you don't know whether Y goes with X or X2 
      And I think it's pretty clear that both need to be supported.

And that by itself makes a resource required. However ...

* You can't have relationships between titles (there's nothing to relate to), e.g. that one title is a variant of another
* You need to create new properties for every type of title, rather than using classes and a consistent relationship from work to title
* You can't have other properties of titles, such as status [not that I agree with this particular example property, but have heard it stated as a requirement]
* You can't have relationships to other resources, such as the transcriber [ditto]

So if all we ever need is one or more equally preferred strings as the title, and there are no parts, properties or relationships, then we should just use dc:title with a string.  Otherwise, we need to use a resource.

Rob


On Fri, May 15, 2015 at 7:14 AM, Stephen Hearn <[log in to unmask]> wrote:
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)

Stephen


On Fri, May 15, 2015 at 8:49 AM, Cindy Wolff <[log in to unmask]> wrote:

What is meant by “artisanal” cataloging?

 

Cindy

 

 

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.

 

Stephen 

 

 

 

 

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 :)

 

Rob

 

--

Rob Sanderson

Information Standards Advocate

Digital Library Systems and Services

Stanford, CA 94305



 

--

Stephen Hearn, Metadata Strategist

Data Management & Access, University Libraries

University of Minnesota

160 Wilson Library

309 19th Avenue South

Minneapolis, MN 55455

ORCID:  0000-0002-3590-1242




--
Stephen Hearn, Metadata Strategist
Data Management & Access, University Libraries
University of Minnesota
160 Wilson Library
309 19th Avenue South
Minneapolis, MN 55455
ORCID:  0000-0002-3590-1242



--
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305