A straw poll was conducted to determine the level of CC:DA support for the proposal. The question was: should ALA support the proposal for an option to supply the name of the larger jurisdiction?

+

+

Responses: 19 yes, 5 no

+

+

Overall, CC:DA supports the proposal to provide an option to supply the name of the larger jurisdiction if considered necessary for identification or access.

+

+

- Robare, 9/21/11

+

+

+

== Summary of discussion, 9/12/11 ==

+

+

There is no consensus on this proposal; there are strong opinions in favor and in opposition, as well as some in the middle. More people expressed disagreement with the proposal or concern about the ramifications than support, but not by much. I'll just attempt a general summary of the reasons.

+

+

- Disagree: it is a step back from principle of representation (0.4.3.4); it introduces an option that is already addressed by other RDA instructions (2.20.6 through 2.20.9).

+

+

- Support: providing this option is in the best interest of the user (0.4.2.1); there are too many non-distinctive placenames; putting the information in a note separates it in the display, reducing its usefulness.

+

+

Other comments:

+

- More long term solution would be to have two elements, place of publication (etc.) 1) as seen on the resource; and 2) as a controlled data element.

+

- Editorial: new examples at 2.8.2.3 include a comma: Dublin, [Ireland]

+

+

We will probably do a straw poll on this one later this week.

+

+

- Robare, 9/12/11

+

Line 33:

Line 62:

I'm torn on this one, too. Like John, I like the proposal "emotionally", but Robert and John make good points that is does represent a step back from RDA principles. On the third hand, I'm also thinking that place of publication, etc. might be an element that would be better treated as coming from a controlled vocabulary rather than as an element to be transcribed. If a purpose of this element is to identify a resource, then it is important to know if the resource was published in Dublin, Ohio vs. Dublin, Ireland, and I think having that information in a note (i.e. a textual string) does tend to bury it. Maybe a larger or more long-term solution is to have two elements, place of publication (etc.) 1) as seen on the resource and 2) as a controlled data element. We already do this in MARC, with the 260 subfield "a" and the 008 place of publication. RDA doesn't talk about the latter, obviously, but maybe something like it should be incorporated into RDA, however that might work. Rolla, 9/2/11

I'm torn on this one, too. Like John, I like the proposal "emotionally", but Robert and John make good points that is does represent a step back from RDA principles. On the third hand, I'm also thinking that place of publication, etc. might be an element that would be better treated as coming from a controlled vocabulary rather than as an element to be transcribed. If a purpose of this element is to identify a resource, then it is important to know if the resource was published in Dublin, Ohio vs. Dublin, Ireland, and I think having that information in a note (i.e. a textual string) does tend to bury it. Maybe a larger or more long-term solution is to have two elements, place of publication (etc.) 1) as seen on the resource and 2) as a controlled data element. We already do this in MARC, with the 260 subfield "a" and the 008 place of publication. RDA doesn't talk about the latter, obviously, but maybe something like it should be incorporated into RDA, however that might work. Rolla, 9/2/11

+

+

I'm not torn, I quite favor the option as in the best interest of the user. I'm not sure how this will compromise machine processing since the data is clearly tag by the presence of the brackets and a computer can easily be programmed to ignore or not the data. And having said that, I'm thinking machine processing might be helped since a computer would be able to use the data to correctly make the association that publication was in Dublin, Ohio rather Dublin, Ireland. I also concur with Robert's comment about the incorrect use of the comma. Tarango (CRS) 9/2/2011

+

+

I am not in favor of this addition, since it introduces an option that is already addressed by other RDA instructions (see 2.20.6 through 2.20.9). Are there other optional additions in RDA that do this?

+

- Glennan (PCC), 9/4/11

+

+

Strongly support this proposal. There are too many non-distinctive (or not generally known) placenames; we should be saving the reader's time by supplying the larger jurisdiction when it is easy to do this. --Lipcan (ARLIS/NA) for Elizabeth O'Keefe (Morgan Library & Museum), 9-5-2011

+

+

Reflecting the internal conflict that appears to accompany this proposal, I don't agree with my colleague from the Morgan, for the reasons stated by Kathy, Robert and John above. Beyond Kathy's point that the issues are already addressed elsewhere -- which by itself turns me against this proposal -- the philosophical repercussions of approving it are further-reaching than I am comfortable with. --Lipcan (ARLIS/NA), 9-5-2011

+

+

I do not agree with this proposal, largely for the reasons mentioned by Glennan above. Winzer, 9/5/2011

+

+

Very strongly support this proposal. Virtually all known user displays of bibliographic data widely separate the Place of Production/Publication/Distribution/Manufacture elements from any notes which may relate to those elements, and therefore putting information essential to the understanding of the elements into a note drastically reduces the usefulness of those elements. I'm not sure I really understand John Myers' concern about "If future convenience of the user is predicated on the speed and utility of machine processing, then this compromise will be a bad idea." What machine processing would be impeded by including bracketed additional data? Or is the problem that those agencies wishing to apply the option would be saddled by more work because elements which might get filled in automatically from the resource won't have that bracketed additional data? Peter Rolla gets at the heart of the matter here: we are torn between the two purposes of these RDA elements. RDA does not explicitly state those purposes, unfortunately; we are left to deduce them from 0.4. The only reason I can imagine for disallowing the addition of the larger place name would seem to be an undue overemphasis on (and narrow interpretation of?) the principle of Representation (0.4.3.4), at the expense of any other principles, thus working against the objective of Responsiveness to User Needs (0.4.2.1). Other than the Representation issue, I am *very* curious about what philosophical repercussions Dan Lipcan could be alluding to. K. Randall, 9/6/11

+

+

Peter Rolla's comment has me further contemplating the title of RDA and the two functions it addresses, description and access. I am also mindful of the FRBR user tasks. I think the challenge here arises from the foundation of this element in its predecessors in the card environment which, lacking separate indexing for place or publisher, tended to give priority to identification via transcription. Selection did have a place here, witness the option to add the larger jurisdiction. In the online environment, the competing directives of description and access are brought to the fore. The solution, it seems, would be to reserve a descriptive element to transcribe what is on the resource, with some other controlled element to afford consistent access. MARC 21 field 752 offers this, although its employment has previously been limited to the Rare Book community and not uniformly at that. Is it time to go the route of serials access and split the desciptive and access functionalities for this datum? If so, what is the appropriate mechanism within the rules to accomplish that? MYERS, MARBI Liaision, 2011/09/13

+

+

To continue, somewhat out of the scope of CCDA's charge but in keeping with my MARBI liaison role, if the descriptive and access components of Place of Publication (and possibly Publisher, etc., as long as we are upsetting the apple cart), what will be the coding mechanisms to accomplish this? Obviously, within MARC, separate fields or possibly separate subfields would need to be employed much as we employ 490 and the 8XX family. If we look outside of MARC to XML or other markup formats, I have repeatedly been struck by its flexibility to use tagging to identify the nature of transcribed data, but also to embed within the tagging the use of attribute coding -- this affords the best of both worlds, the ability to incorporate and closely associate both transcribed and controlled forms of data. MYERS, MARBI Liaison, 2011/09/13

Update, Straw Poll Results, 9/21/11

A straw poll was conducted to determine the level of CC:DA support for the proposal. The question was: should ALA support the proposal for an option to supply the name of the larger jurisdiction?

Responses: 19 yes, 5 no

Overall, CC:DA supports the proposal to provide an option to supply the name of the larger jurisdiction if considered necessary for identification or access.

- Robare, 9/21/11

Summary of discussion, 9/12/11

There is no consensus on this proposal; there are strong opinions in favor and in opposition, as well as some in the middle. More people expressed disagreement with the proposal or concern about the ramifications than support, but not by much. I'll just attempt a general summary of the reasons.

- Disagree: it is a step back from principle of representation (0.4.3.4); it introduces an option that is already addressed by other RDA instructions (2.20.6 through 2.20.9).

- Support: providing this option is in the best interest of the user (0.4.2.1); there are too many non-distinctive placenames; putting the information in a note separates it in the display, reducing its usefulness.

Other comments:
- More long term solution would be to have two elements, place of publication (etc.) 1) as seen on the resource; and 2) as a controlled data element.
- Editorial: new examples at 2.8.2.3 include a comma: Dublin, [Ireland]

We will probably do a straw poll on this one later this week.

- Robare, 9/12/11

General comments

This proposal goes to the heart of some of the changes inherent in transitioning from AACR2 to RDA, namely the abandonment of concise presentation of data for a stricter WYSIWYG approach to transcription. If this piece of information is important, RDA allows it to be recorded in a note, so the information will be present just not in the convenient place we are used to seeing it (and possibly inconveniently buried in a welter of other notes). Emotionally, I'm all for it; intellectually, I realize it would be a significant compromise to RDA's approach to transcription. If future convenience of the user is predicated on the speed and utility of machine processing, then this compromise will be a bad idea; if it continues to be predicated on the convenient display of data, then it may be worth considering. I can't say which side of the issue I fall on, sadly. MYERS, MARBI Liaison, 2011/08/30

I have no real objection to permitting this as an option, but, in principle, it would be a step backward from the direction we thought we were going in. A minor observation on punctuation: I think Dublin, [Ireland] would be a change from current practice, which would be Dublin [Ireland]. R.Rendall, 8/30/11

I'm torn on this one, too. Like John, I like the proposal "emotionally", but Robert and John make good points that is does represent a step back from RDA principles. On the third hand, I'm also thinking that place of publication, etc. might be an element that would be better treated as coming from a controlled vocabulary rather than as an element to be transcribed. If a purpose of this element is to identify a resource, then it is important to know if the resource was published in Dublin, Ohio vs. Dublin, Ireland, and I think having that information in a note (i.e. a textual string) does tend to bury it. Maybe a larger or more long-term solution is to have two elements, place of publication (etc.) 1) as seen on the resource and 2) as a controlled data element. We already do this in MARC, with the 260 subfield "a" and the 008 place of publication. RDA doesn't talk about the latter, obviously, but maybe something like it should be incorporated into RDA, however that might work. Rolla, 9/2/11

I'm not torn, I quite favor the option as in the best interest of the user. I'm not sure how this will compromise machine processing since the data is clearly tag by the presence of the brackets and a computer can easily be programmed to ignore or not the data. And having said that, I'm thinking machine processing might be helped since a computer would be able to use the data to correctly make the association that publication was in Dublin, Ohio rather Dublin, Ireland. I also concur with Robert's comment about the incorrect use of the comma. Tarango (CRS) 9/2/2011

I am not in favor of this addition, since it introduces an option that is already addressed by other RDA instructions (see 2.20.6 through 2.20.9). Are there other optional additions in RDA that do this?
- Glennan (PCC), 9/4/11

Strongly support this proposal. There are too many non-distinctive (or not generally known) placenames; we should be saving the reader's time by supplying the larger jurisdiction when it is easy to do this. --Lipcan (ARLIS/NA) for Elizabeth O'Keefe (Morgan Library & Museum), 9-5-2011

Reflecting the internal conflict that appears to accompany this proposal, I don't agree with my colleague from the Morgan, for the reasons stated by Kathy, Robert and John above. Beyond Kathy's point that the issues are already addressed elsewhere -- which by itself turns me against this proposal -- the philosophical repercussions of approving it are further-reaching than I am comfortable with. --Lipcan (ARLIS/NA), 9-5-2011

I do not agree with this proposal, largely for the reasons mentioned by Glennan above. Winzer, 9/5/2011

Very strongly support this proposal. Virtually all known user displays of bibliographic data widely separate the Place of Production/Publication/Distribution/Manufacture elements from any notes which may relate to those elements, and therefore putting information essential to the understanding of the elements into a note drastically reduces the usefulness of those elements. I'm not sure I really understand John Myers' concern about "If future convenience of the user is predicated on the speed and utility of machine processing, then this compromise will be a bad idea." What machine processing would be impeded by including bracketed additional data? Or is the problem that those agencies wishing to apply the option would be saddled by more work because elements which might get filled in automatically from the resource won't have that bracketed additional data? Peter Rolla gets at the heart of the matter here: we are torn between the two purposes of these RDA elements. RDA does not explicitly state those purposes, unfortunately; we are left to deduce them from 0.4. The only reason I can imagine for disallowing the addition of the larger place name would seem to be an undue overemphasis on (and narrow interpretation of?) the principle of Representation (0.4.3.4), at the expense of any other principles, thus working against the objective of Responsiveness to User Needs (0.4.2.1). Other than the Representation issue, I am *very* curious about what philosophical repercussions Dan Lipcan could be alluding to. K. Randall, 9/6/11

Peter Rolla's comment has me further contemplating the title of RDA and the two functions it addresses, description and access. I am also mindful of the FRBR user tasks. I think the challenge here arises from the foundation of this element in its predecessors in the card environment which, lacking separate indexing for place or publisher, tended to give priority to identification via transcription. Selection did have a place here, witness the option to add the larger jurisdiction. In the online environment, the competing directives of description and access are brought to the fore. The solution, it seems, would be to reserve a descriptive element to transcribe what is on the resource, with some other controlled element to afford consistent access. MARC 21 field 752 offers this, although its employment has previously been limited to the Rare Book community and not uniformly at that. Is it time to go the route of serials access and split the desciptive and access functionalities for this datum? If so, what is the appropriate mechanism within the rules to accomplish that? MYERS, MARBI Liaision, 2011/09/13

To continue, somewhat out of the scope of CCDA's charge but in keeping with my MARBI liaison role, if the descriptive and access components of Place of Publication (and possibly Publisher, etc., as long as we are upsetting the apple cart), what will be the coding mechanisms to accomplish this? Obviously, within MARC, separate fields or possibly separate subfields would need to be employed much as we employ 490 and the 8XX family. If we look outside of MARC to XML or other markup formats, I have repeatedly been struck by its flexibility to use tagging to identify the nature of transcribed data, but also to embed within the tagging the use of attribute coding -- this affords the best of both worlds, the ability to incorporate and closely associate both transcribed and controlled forms of data. MYERS, MARBI Liaison, 2011/09/13