Stephen – thanks for bringing this up. The wording is awkward:

The Title String
We informally define the “Title String”: one or more of the title components (see properties tables) strung together (it could be a constructed title or a simple title). The Title String may be represented as the value of rdfs:label within bf:Title. (Alternatively, it may be parsed out into its component via the properties of bf:Title, in which case it may be omitted, or it may be redundantly included.)

This would probably be better expressed as follows:

4. The Title String and its Components
We informally define the “Title String”: one or more of the title components (see properties tables) strung together (it could be a constructed title or a simple title). The Title String may be represented as the value of rdfs:label within bf:Title. In addition, title string components may be parsed out separately.

Ray

From: Bibliographic Framework Transition Initiative Forum [mailto:[log in to unmask]] On Behalf Of Stephen Hearn
Sent: Wednesday, November 04, 2015 2:40 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] BIBFRAME vocabulary 2.0 draft specifications posted

The BIBFRAME 2.0 Titles draft removes bf:formDesignation as a property of bf:Title and does not seem to include a property for language. Under 4. Title string, the draft says, "The Title String may be represented as the value of rdfs:label within bf:Title. (Alternatively, it may be parsed out into its component via the properties of bf:Title, in which case it may be omitted, or it may be redundantly included.)

If bf:Title does not include all the property types which might figure in a bf:WorkTitle/rdfs:label constructed according to RDA (e.g., language or "Selections"), does that open up the possibility of partially parsed title strings? If so, should point 4 say " ... (Alternatively, it may be parsed out into its components via the properties of bf:Title, in which case it may be omitted, may be included redundantly; or may be included to express qualifiers or a preferred order not represented in the parsed properties.)"?

Stephen

On Tue, Nov 3, 2015 at 11:06 AM, McCallum, Sally <[log in to unmask]> wrote:

BIBFRAME 1.0 has been stable for more than a year now. We have intentionally kept it stable so that implementers could experiment with it and so that we could learn from discussion and consultation the issues of the vocabulary and how it might be improved. We at LC implemented a pilot that is ongoing now using the 1.0 vocabulary – an exercise that also gave us “feedback”.

Then several months ago, LC started posting for review proposed changes to the BIBFRAME vocabulary in preparation for its redevelopment as BIBFRAME 2.0. The change proposals were prepared after reviewing the comments received on the listserv over the last year and comments from invited experts – along with dealing with our own implementation experiences. Discussion of these proposals and consultations proved quite fruitful and helped significantly in the development of the draft 2.0 specification. We thank you all for your comments and advice.

We are referring to the current vocabulary in use as BIBFRAME 1.0 and the developing draft vocabulary as BIBFRAME 2.0. There are seven “draft specifications” (targeted at different components of the vocabulary) posted at http://www.loc.gov/bibframe/docs/ . Specifically:

Identifiers and Notes

Administrative Metadata