Print

Print


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
>>
>> Ph: 612-625-2328
>>
>> Fx: 612-625-3428
>>
>> 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
> Ph: 612-625-2328
> Fx: 612-625-3428
> ORCID:  0000-0002-3590-1242
>



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