-BAC.GC.CA
Subject: Re: [RDA-L] 336, 337, 338 and the post-MARC environment
On 09/05/2013 23:11, Jonathan Rochkind wrote:
My software, and by extension, my users using my software, use the MARC leader,
007, 008, 040, and other fixed/coded fields, every day. It is not data that
nobody uses or can us
e of coded values is hardly a unique innovative sin to RDA, as many
seem to be suggesting, although they do it mostly with sarcasm so
sometimes it's hard to tell exactly what they are suggesting.
On 5/9/2013 5:05 PM, James Weinheimer wrote:
On 09/05/2013 22:17, Jonathan Rochkind wrote:
On 5
On 5/9/2013 3:56 PM, Gene Fieg wrote:
And how are these field going to be displayed in an easily
understandable manner to the patron. Will we need a priest of RDA near
the shoulder of every patron as she/he searches for that DVD she knows
is in the library somewhere, because the AACR2 catalog to
Regardless of Berne convention and laws, don't confuse the surrogate for
the item described. I don't think I copyright statement on the
_cataloging record_ but refering to the copyright of the item described
ever played any legal role in establishing copyright on the item
described, even in cas
Okay, here's what I think is a strange idea implicit in the arguments
many keep making including you:
That if a _searcher_ doesn't want to see something, it should not be in
the record. That a record is for _showing to a searcher_.
This leads you to question RDA based on "very strange RDA "sp
Yes, that doesn't surprise me. But they're going to care if one
manifestation is PDF, and another is Kindle, and another is mobi, and
another is ePub. (They might even know what those words mean, but
they're going to care that if they have an e-reader, some of those
formats will work on their p
On 10/25/2012 1:20 PM, Benjamin A Abrahamse wrote:
" If a library holds software, mightn't a user want to see a list of
all the software the library holds, whether games or word processors
or what have you"
I suppose. But that seems to me like a less direct, or usual user
task than, "Show me wh
On 10/25/2012 12:57 PM, Benjamin A Abrahamse wrote:
Yes, a computer game is a "computer program" but I don't think most
users think of it that way.
I am not sure if that's true or not. If a library holds software,
mightn't a user want to see a list of all the software the library
holds, whet
You have "DVD", "Compact Disc" and "Comic Book" as GMD's in 245$h?
This is curious to me, and I wonder what your data source is for records
with these GMD's. None of those are on the 'standard' list of GMDs, and
you won't generally find any of those used as GMD's on MARC from OCLC or
LC.
Th
I'm not actually sure that the need to distinguish between expressions
is that important -- outside of particular minority cases involving
voluminous works with many editions that are the subject of study by
literary scholars. I'm not saying it's useless, but I'm dubious that
it's as important
The title statement has never been that optimal for collocating works,
because even when it's not been left to cataloger judgement but has been
recorded according to very specific rules -- they were rules based on
how the title was printed on the item-in-hand (manifestation), which
isn't necces
No, but, see, the definition of "composer (expression)" DOES acknowledge
what it means to be linked to the _expression_. Thanks to whoever
pointed that out:
" by adding music to a work that originally lacked it, by composing new
music to substitute for the original music, or by composing new m
On 10/9/2012 12:37 PM, JOHN C ATTIG wrote:
I would not focus too much on whether the relationship applies to all
expressions of the work. If the relationship involves the realization
rather than the creation of the work, then it is an expression-level
relationship.
The problem with this is t
I understand why a composer can only be 'creator' (rather than
'contributor') to a musical work.
But I don't understand why a composer can't be a contributor (rather
than creator) to a 'work' as well as 'expression', when the composer's
contribution is a fundamental part of the work as a whole
Right, I was intentionally drawing the analogy that you did not draw, I
realize. Why do your think your argument does not apply to textual authorship
the way it applies to directors of movies?
One answer may be that our data simply isn't capable of answering these
questions for movies because o
Do you apply this same thinking to any kind of authorship/creating, Mike?
There's no reason for the catalog to be able to provide a list of things by
Mark Twain, because the user can consult a standard reference work to get the
list of everything by Mark Twain, and then use the library catalog t
r is
only interested in those held by the library, the library catalog is the
appropriate place. I don't know why you changed the question as a way to
question my answer.
I hardly believe that my answer was not credible or understandable.
kc
On 9/21/12 11:01 AM, Jonathan Rochkind wrote:
> Why on earth, when the question is "a list of the movies directed by Clint
> Eastwood" would any reference librarian point to the catalog?!
There is only one answer to this: Because someone wants a list of movies
directed by Clint Eastwood that are held by the library, that she can go check
If you care about machine actionable, that (c) character is really
annoying to those working on machine access. It's not intractable, it
can be dealt with, but it's just one more annoyance in MARC requiring a
workaround. Especially in a 264 where the element is already machine
identified as a cop
This is not new to RDA. It is a problem inherited from AACR2-style 'citations',
and MARC. But:
730 0 $i Summary (work): $t Water availability in the Ovens (Summary)
The problem with this, is there's absolutely no way for a computer to actually
_look up_ the 'work cited' here. It's going to be l
My Blacklight-based catalog makes use of the 043's when present. It's
certainly not true that "no" online system ever made use of it.
On 6/12/2012 12:55 PM, Kevin M Randall wrote:
-Original Message-
Unfortunately, most people did not bother with the 043 field, in
particular, because no
On 5/19/2012 3:07 PM, Karen Coyle wrote:
Joe, this is the thrust of my blog post, which started this thread:
http://kcoyle.blogspot.com/2012/05/rda-dbms-rdf.html
and I say:
" Where the goal in relational database design is to identify and
isolate data elements that are the same, the goal in li
On 5/19/2012 10:52 AM, Karen Coyle wrote:
This is what worries me about FRBR and the assumptions that every
bibliographic record will be made up of at least four and probably more
like 6-8 table joins. If every record to be displayed requires a join of
a Manifestation, an Expression, and a Work
Certainly you can come up with an infinite number of wrong ways to do it that
won't get the results you want. With any given technology. I do not understand
why you are trying to come up with wrong ways to do this arbitrary goal, you
seem to be working on refining your software approaches with
On 5/15/2012 11:34 AM, James Weinheimer wrote:
Although MARC needs to change, and has needed it for a very long time, I
don't see how changing the format would improve the subject headings.
I did not mean to say that changing from MARC to somethign else, by
itself, would do anything at all to
On 5/14/2012 8:52 PM, Karen Coyle wrote:
No, that is not what I meant. Of course you can retrieve records in a
given order, and we do all the time. It's about using the headings in
the MARC records to establish that order. So here's the question I put
to Mac:
Sure you can use the headings in t
On 5/14/2012 10:45 AM, Karen Coyle wrote:
No, I'm saying that JSC made a claim that RDA was developed on RDBMS
principles
Where do you find this claim?
I've seen documentation that FRBR (and by extension RDA) was developed
based on entity-relational modelling.
That's not the same thing as
Yeah, form/format/media/content/carrier are _really complicated_ to
understand.
It turns out that most people's internal mental models for these things
in fact aren't internally consistent at all (even librarians). Which is
kind of why AACR2/MARC turned into the mess it is around this stuff. A
On 4/8/2012 11:13 AM, Elizabeth O'Keefe wrote:
In a century or so, we may be kicking ourselves because we
didn't define a separate field for the object type, and require its use
even for books, so users who desire these quaint artifacts can FISO
them.
You don't have to wait a century; this is
On 4/2/2012 2:23 PM, Jenifer K Marquardt wrote:
Jonathan,
Often there is good information concerning the person available on the item
cataloged such as affiliaton with a particular institution, other titles
published, or place of residence. While this information cannot be used to
establish
aculty.washington.edu/~aschiff
~~
On Mon, 2 Apr 2012, Jonathan Rochkind wrote:
I am not a cataloger, but something that's always confused me:
Why do you need an 'authority record' at all for an 'undifferentiated
name'? What's the authority/authorization
i
I am not a cataloger, but something that's always confused me:
Why do you need an 'authority record' at all for an 'undifferentiated
name'? What's the authority/authorization involved? In a heading that
doesn't actually correspond to a particular person (or even a particular
bibliographic i
a few
facts: There is LCRI 21.0D where it is stipulated that LC will not put in
relator codes. They are also not required in BIBCO.
Jonathan Rochkind responded:
This is awfully circular. You started out saying that it was a mistake for the
local catalog to try to do this, it was the 'wro
On 3/17/2012 6:42 AM, James Weinheimer wrote:
Why is the local catalog definitely not the correct tool here? Because
of a few facts: There is LCRI 21.0D where it is stipulated that LC
will not put in relator codes. They are also not required in BIBCO.
This is awfully circular. You started out
On 2/22/2012 5:25 PM, James Weinheimer wrote:
This is why I mentioned in my paper in Buenos Aires the NPTEL free
online courses that lots of people would really and truly find useful.
There are so many of these sorts of resources that it is absolutely
astounding! Unfortunately (I am definite
On 2/22/2012 4:44 PM, James Weinheimer wrote:
So, if the ultimate goal is for us to enter the linked data world, why
do we have to adopt the RDA/FRBR record structure first? Why not do
just do it now?
I think you are right that we don't need to wait for "RDA/FRBR record
structure". And pers
On 2/22/2012 3:59 PM, Karen Coyle wrote:
The question then becomes: is there a way to use FRBR as the
conceptual basis of our data without limiting ourselves to a single
implementation that insists that each entity be a separate record?
(Jonathan will wonder "why not", and I can only point to t
On 2/21/2012 3:29 PM, Karen Coyle wrote:
Is linked data the only possible future? No, but I assume that the
future includes data in the Web, Web-friendly identifiers, and new
information views derived from mash-ups between what are now separate
data stores.
Agreed. If "linked data" means som
On 2/21/2012 1:38 PM, Karen Coyle wrote:
FRBR claims to be based on a "relational" model, as in "relational
database." That is not tomorrow's data model; it is yesterday's,
although it is a step toward tomorrow's model. The difficulty is that
FRBR was conceived of in the early 1990's, and com
On 2/15/2012 4:47 PM, Karen Coyle wrote:
On 2/15/12 12:32 PM, Jonathan Rochkind wrote:
But I believe strongly that it's important when creating
and sharing data that we know whether the data is about a particular
manifestation, a particular expression, or a work as a whole.
I suggest re
On 2/15/2012 2:52 PM, Karen Coyle wrote:
You refer to FRBR as a mental model. The FRs themselves often call
themselves "conceptual models." I'm fine with FRBR as a mental model,
but not so much with it as a data model. I think that FR as a data
model is problematic. Anyone can use whatever me
On 2/15/2012 12:47 PM, Brenndorfer, Thomas wrote:
For example, routinely adding the translator relationship is such an obvious
way to distinguish translations, yet this has not always been done. Likewise in
adding the illustrator relationship for distinguishing expressions. It's easy
to under
I still think the WEMI model (or 'ontology') is in fact _crucial_ for
linked data applications, rather than problematic.
Linked data applications rely on taking data from multiple sources, and
being able to tell when it's about the same 'thing'.
But what is a 'thing', in the 'bibliographic un
On 2/14/2012 4:38 PM, Karen Coyle wrote:
Yet we valued the new cataloging rules enough to fund those.
Hmm, or certain entities thought they could make enough money selling em
to make it a good investment.
Which has it's own problems, yeah. (a standard that you need to pay to
see is much le
"Dublin core application profiles" were, if I understand it right,
supposed to be a specific technical thing, which among other things, was
a machine readable/actionable document itself, kind of like a formal
schema/vocabulary, but addressing things at an even higher level of
abstraction. I ne
details, etc.)
On 1/26/2012 11:33 AM, Jonathan Rochkind wrote:
I suspect that in many cases "most popular work by" is one of the best
ways to disambiguate people with same names, 'best' as far as most
useful to many users in many cases.
Of course, 'most popular work b
I suspect that in many cases "most popular work by" is one of the best
ways to disambiguate people with same names, 'best' as far as most
useful to many users in many cases.
Of course, 'most popular work by' should NOT be included in a
heading-identifier, as it's too long, and may change, etc.
On 1/18/2012 3:21 PM, John Hostage wrote:
Maybe the idea of hard-wiring dates and other additions into access points has
outlived its usefulness. It made sense in a card catalog, but maybe not so
much in an online world. Dates and other information can be carried as
separate elements in an a
On 1/9/2012 11:23 AM, Karen Coyle wrote:
The difficulty is that there appears to be a desire to create a
whole/part from, say, a Manifestation to an Expression, which does not
seem to be valid in the FRBR model, even though it is conceptually
logical.
I'm not sure it's conceptually logical
On 1/5/2012 5:06 PM, Karen Coyle wrote:
Then, if our assumption is that users are interested in the individual
Works as well as, or instead of, the aggregate, then another entry has
to be made for each individual Work as well. I don't think that's how
most of us envision FRBR.
Is "another ent
Yep, I understand those issues that you've mentioned before. They are
all (with the possible exception of #7) cases of software being broken.
If you have to mangle data to meet the expectations of broken software,
well, then you have to. But it doesn't mean the data is broken. You are
certainly
Kind of off topic, but curious why you don't think relator codes are the
right thing to do. If we're listing 3 or 5 or 10 people or entities
'responsible' for an artistic work, why wouldn't we want to be able to
say the nature/role of each entities responsibility? Or, if we do, but
relator cod
On 9/29/2011 1:31 PM, J. McRee Elrod wrote:
Our experience with Java has been more positive, but one advantage of
remaining with binary MARC is skill transfer for cataloguers and ILS
programmers. (This Java comment is based on second hand information;
I have not programmed since 1966.)
I am s
If you are changing the MARC format in non-backwards-compatible ways
anyway why would you choose a 'binary' format relying on byte
offsets (something few formats invented since the 1980s have done),
instead of a more modern XML or JSON based format?
I have absolutely no idea what you mean
On 9/19/2011 4:55 PM, J. McRee Elrod wrote:
"The copy editor will also have a JSC contact for queries regarding
RDA content and intended meaning."
So *one* member of the JSC will be making these important decisions?
The passage you quoted does not in fact say what you conclude, so that's
not
On 9/15/2011 2:19 PM, Damian Iseminger wrote:
Because jazz relies heavily on improvisatory elements, the bootleg performances
will be different from the legit recording. Are these also new works? I would
have to vote yes.
Really? I mean, I think the answer here is based on what patrons would
On 9/12/2011 3:55 PM, Karen Coyle wrote:
Quoting Jonathan Rochkind :
Just like the system can process 336/337/338 to summarize as icons,
it could process them to summarize as text too.
Except that I've been told, off list, that there is not accepted set
of text that they wou
There's no reason to restrict coded/controlled values to 'fixed
fields'. I'm not entirely sure what we consider 'fixed fields' -- are
the coded values in an eg 041 considered a fixed field? Those aren't
'fixed' byte size like say the 006 or 008, but they are controlled from
a finite vocabular
I'm not a huge fan of icons, but the only choices are NOT icons or
un-mediated verbatim echo'ing of 336/337/338.
Just like the system can process 336/337/338 to summarize as icons, it
could process them to summarize as text too.
I think of 336/337/338 as an internal controlled vocabulary/onto
All of those choices Mac makes will make it impossible to relate
336-337-338 based on order-of-fields in record, which was one of Karen's
brainstorming ideas. (repeating a's, not repeating a duplicate 337, etc)
So that confirms that's unlikely to work in actual practice, if Mac's
not the only o
On 9/10/2011 4:24 PM, Karen Coyle wrote:
I think the user probably wants a single expression that gives her an
idea of what the resource is. I'm not convinced that the 366/7/8
separation and terminology supports a real function, so I'd like to
hear from folks with more knowledge about what fu
On 9/10/2011 1:50 PM, Karen Coyle wrote:
There are two ways:
1) fields in MARC are to be kept in the order in which they appear in
the directory. So if you were to create
366
367
368
366
367
368
the fields should remain in that order when processed. Now I know that
Mac will shoot back that ma
On 9/10/2011 1:06 PM, Julie Moore wrote:
I guess, again, my question would be: how does the computer know to
put which things together?
You are absolutely right -- it is a huge problem in MARC (not a problem
with RDA, a problem with how we're encoding it in MARC) that when you
have multiple
On 9/9/2011 3:34 PM, Julie Moore wrote:
Thanks, Lori,
I'd be happy to send this in to Kelley as a revision proposal. I look
forward to your sending me the interim guidelines.
In the meantime, I was hoping to generate some conversation about this
on this listserv. Do folks think this (adding
You _can_ do things this way, out of neccesity, but it's definitely not
preferable from a data mangement point of view, right? We're talking
about the difference between a a single 'foreign key' in each record
stating that it's part of a certain work (preferable from data
management point of v
On 8/4/2011 3:33 PM, Karen Coyle wrote:
In general I am having a hard time understanding how we will treat
these kinds of composite headings in any future data carrier. They
seem to be somewhat idiosyncratic, in that what data gets added is up
to the cataloger, depends on the context, and proba
It's true that as a standard it is intended for cross-system
communciation. The standard was not intended to be for internal system
representation. So James is kind of right, right?
It's also true that most ILS's and other library bibliographic systems
(say, cooperative cataloging stores :) )
I think you are on the right track with motivations.
Is the SMD already in the record somewhere?
If it is, I think the better effort would be getting your ILS display to
include the SMD in the heading next to the GMD.
If it is not, then perhaps a change to rules or guidelines to suggest
addi
On 6/16/2011 1:21 PM, J. McRee Elrod wrote:
Some are qualifying the GMD, e.g., [videorecording (Blu-ray)],
This practice will make it even harder for software to interpret and act
upon 'format' information encoded in this field.
On 6/2/2011 4:54 PM, Arakawa, Steven wrote:
Do public service staff examine catalog records to verify that access points
have been justified? (Don't most brief records eliminate such notes?) Do they
care if author main entry is used instead of title main entry if there are more
than 3 authors
Won't it have an alternate 'access point' for the other nation(s) too,
and thus be findable at either alphabetical location regardless of which
nation comes first in the given translation?
On 6/2/2011 4:18 PM, Pat Sayre McCoy wrote:
Adger asked what to tell the reference librarians:
Mac said
Yeah, if RDA _required_ all capital titles, that might be bad. I don't
think anyone thinks all capital titles are preferable.
But in the actual real world eco-system, where we're often going to be
harvesting data from other sources rather than creating it ourselves
from -- and not going to ha
Then why do you choose to make titles still on order so hard to read by
vision impaired people? This is entirely unacceptable, as you say
"deciding what can be read by whom", why have you decided that
vision-impaired people won't be able to read the titles of items on order.
Just kidding, I k
RDA should be delayed because it didn't change AACR2 _enough_ for your
tastes, because it left some AACR2 practices intact that you think
should be changed? That's not a reason to delay a standard. That's
ridiculous. If you wait until RDA is perfect in the judgement of
everyone involved, it w
MARC also insists it's not a display mechanism. MARC is a transmission
format.
On 4/29/2011 12:37 PM, Gene Fieg wrote:
I am not one of the people on all of these committees, but I think
discussions of MARC keep coming up on the RDA list is because RDA
insists that it is not a display mechanism
Anyone have an answer to why RDA requires you to enter "[date of
publication not identified]" instead of just leaving the data element blank?
Just leaving it blank seems more efficient for the cataloger AND easier
for software to deal with (not having to know that the magic string
"[date of pu
Do you mean the real copyright sign glyph, or do you mean a c in
parens? Or can people use whatever they want?
It's not that this individual thing is THAT hard for software to pull
out; it's that the piling on of all these individual "not that hard"
things results in a much more expensive and
ows is the real primary contributor as the 1xx (ie linked entity?).
if so, that would seem potentially a mistake, possibly.
On 4/27/2011 2:18 PM, James Weinheimer wrote:
Jonathan Rochkind wrote:
But in cases where it is obvious what's going on it seems to me
it would be preferable f
If the cataloger is pretty confident that this book is REALLY written by
Charles Schultz, is there any reason (in priniciple or in code) that she
can't simply add "Schultz, Chares..." as the controlled heading/access
point/1xx?
Snoopy would still be in the transcribed 245 statement of responsi
nnot be left up to
cataloger's judgment, because that leaves the field open to many
different answers.
Julie
On Mon, Apr 25, 2011 at 7:38 AM, Mark Ehlert <mailto:ehler...@umn.edu>> wrote:
Jonathan Rochkind mailto:rochk...@jhu.edu>> wrote:
> One idea is if
Is there a way to leave an auth record in the file, but clearly mark is
as deprecated/no-longer-legal-to-use?
If there is, yeah, that would be a lot better than actually removing it
from the file, leaving no way for someone to figure out what happened
when encountering records in the wild that
On 4/26/2011 11:03 AM, Gary L. Strawn wrote:
Something different is seen when an institution accidentally creates a
record for an entity already represented by an existing authority
record. Sometimes the institution creates identical records one after
the other, sometimes the duplication is
So your argument is that every single possible field must be created to
be the briefest informative record possible? Really?
Regardless, that's an argument to take up with bibco/PCC I guess.
Apparently they decided that not every single possible field was
neccesary for a BIBCO Standard Record
On 4/25/2011 1:42 PM, Stephen Hearn wrote:
Actually it doesn't remain the same. The current rules say that
identities can and should move on and off of an undifferentiated
personal name authority (UndiffPNA). When an UndiffPNA is reduced to
representing a single identity again, it is recoded as "
link would be a number AND an indication of which
authority file (registry, or what have you) that number was valid for,
wouldn't it?
On Mon, Apr 25, 2011 at 12:55 PM, Jonathan Rochkind <mailto:rochk...@jhu.edu>> wrote:
I'd interprett it differently, I'd say that an &quo
. Otherwise, I am not sure why
you are insisting on arguing with a basic principle accepted by everyone
else doing computer-era data/database/metadata design -- which has been
proven in practice to be a really good prinicple. It's not a controversial
principle. At all. Anywhere except a
od prinicple. It's not a controversial principle. At all.
Anywhere except among library catalogers, apparently.
Jonathan
On 4/25/2011 12:12 PM, James Weinheimer wrote:
On 04/25/2011 05:56 PM, Jonathan Rochkind wrote:
If you maintain the "preferred display form" as your _identifier
r. Because preferred display
forms change, but identifiers ought not to. The identifier should be a
_persistent_ link into your database for the identified record.
On 4/25/2011 11:39 AM, James Weinheimer wrote:
On 04/25/2011 04:27 PM, Jonathan Rochkind wrote:
I agree entirely, controlled headings
red display forms", and I think it would be unwise to think the
desire to change preferred display forms will go away.
So, I'm not sure what the "new" part of the new world of linked data
would be here.
On Mon, Apr 25, 2011 at 10:27 AM, Jonathan Rochkind <mailto:rochk..
On 4/22/2011 3:30 PM, Deborah Fritz wrote:
People *will* be entering free text as this RDA element, so I would like to
know whether anyone has figured out some way that matching algorythms will
be able to reliably match descriptions without the use of consistent terms
in this element.
No, and n
On 4/22/2011 1:13 PM, James Weinheimer wrote:
There is another way of looking at our headings than solely as textual
strings, which is not entirely correct, but rather as identifying
something *unambiguously*. This is exactly what our headings are
designed to do. An identifier does not have t
On 4/21/2011 7:27 PM, J. McRee Elrod wrote:
Karen Coyle said:
Linking is not the same as using identifiers rather than text strings
for entities, although both are considered "best practices" and
linking depends greatly on clear identification.
So these identifiers link to *inhouse* files? "Sh
I thought that RDA as a code used neither GMD _nor_ SMD, replacing those with
the data elements that end up in the new mac 3xx fields? Can anyone confirm
that, that there is no notion of 'smd' in RDA?
If so, there would be no answer to having every SMD registered in the RDA
registry, nor to "wa
and Access / Resource Description and Access
[mailto:RDA-L@LISTSERV.LAC-BAC.GC.CA] On Behalf Of Jonathan Rochkind
Sent: Wednesday, April 20, 2011 9:03 AM
To: RDA-L@LISTSERV.LAC-BAC.GC.CA
Subject: Re: [RDA-L] Cataloguing kits
Using a $8 here to relate 336/337/338 would require that you repeat the
of why Diane's keynote at c4l11 was so
compelling, and why I think the code-cat summit a few of us discussed
that day would be a very good thing.
-Corey
On 4/20/2011 11:24 AM, Jonathan Rochkind wrote:
On 4/20/2011 10:58 AM, J. McRee Elrod wrote:
It was my understanding that one of the pu
On 4/20/2011 10:58 AM, J. McRee Elrod wrote:
It was my understanding that one of the purposes of RDA was to make
machine use of data easier. Repeating 336-338 rather than repeating
$a in a single field when multiple terms apply, increases programming
difficulty dramatically, if any use is to be
Regardless of whether seperate 3xx files or one 3xx with multiple $a's
is used... there's a serious problem with loss of machine retrievable
information when there are multiple constituent elements.
There is no way for software to figure out _which_ 336 entry goes with
which 338 entry, when th
Indeed, actually trying to think in terms of the FRBR conceptual model,
I'm not sure there is even possibly any such thing as "Title page title
of a work."
A manifestation can have a title page title, but a "work" doesn't have
just one title page, it has potentially many manifestations with
d
Only catalogers? The ISSN authority considers them to be different too,
changing the title like that gets you a new ISSN. Note the different
ISSNs at each point "monthly" and/or "the" was added/removed.
The Atlantic 1072-7825
Former titles (until 1993): Atlantic (United States) (0276-9077)
(unt
_
From: J. McRee Elrod [m...@slc.bc.ca]
Sent: Thursday, April 14, 2011 5:09 PM
To: Jonathan Rochkind
Cc: RDA-L@listserv.lac-bac.gc.ca
Subject: Re: Main vs. added entry (was References ...)
Jonathan Rochkind said:
>Interesting for me to think that the card catalog interface o
1 - 100 of 361 matches
Mail list logo
