Well, I don't think this is quite it.
Transcribed elements are always "literal" yes. But our records will
always _definitely_ have some non-transcribed elements---some controlled
elements instead. There is all sorts of 'controlled vocabulary' in our
records. Not just controlled headings, but GMD/SMD selections, various
'relator' codes, language codes, other codes, etc., etc., etc. I think
Karen got off to a good start of identifying all these
mini-controlled-vocabularies of course.
So the issue isn't with transcribed stuff. Transcribed stuff will
certainly always be 'literal'.
The issue Karen raises only applies to controlled (not transcribed)
data, with the issue of _whether_ to transcribe a given piece of data
being a _separate_ issue.
So, as I read 'literal' vs 'non-literal' (based on Karen's explication;
this was confusing to me at first too)
* 'non-literal' means some kind of identifier for a given piece of
controlled vocabulary, that may or may not be end-user-readable but is
resolvable in some system to get more information on that term in the
controlled vocabulary (including end-user-displayable string(s), maybe
relations, etc.)
* 'literal' means an end-user displayable string (although frankly, I
think even many of these strings should _also_ be considered
identifiers, but anyway).
So the actual text for the GMD or SMD is a 'literal'. If instead, a
code for GMD/SMD were included, that would be 'non-literal'.
I think Karen gets it _exactly_ right in her post about this, that
whether a given value is a literal or non-literal (according to these
understandings) is no business of RDA's. It's an issue of
_encoding_---it might be MARC's issue (or any MARC replacement or
competitor). It might be OCLC's issue (or anyone else that accepts
records). But it's an issue of the record encoding, not of the data
itself. Whether it is 'literal' or 'non-literal', the very same semantic
content is there. It's just a question of how it's encoded. That's not a
question for RDA, but for encoding standards. [This is of course NOT
true of the decision whether to transcribe something, control it, or do
both (or neither, I guess). That IS a question of actual semantic
content, not just encoding, and IS an issue for RDA. It is, again, a
_different_ question than the 'literal' vs 'non-literal' one, which only
applies to controlled data as I read it.]
Jonathan
J. McRee Elrod wrote:
Karen Coyle said:
A step related to RDA in which RDA is defined as data elements that can
be encoded for processing should allow literals for all data elements,
but should be defined in such a way that non-literals could be used for
any data element.
Assuming "literal" translates to "transcribed" and "nonliteral"
translates to a pointer such as an ASN or url, then I question that
*any* element may be non-literal. Among those which must be literal
in my view are title as on the item, statement of responsibility as on
the item, series as on the item, and probably imprint as on the item.
Tom Jones may author one work, translate another, and be the criminal
defendant for yet another. Coded relationships (MARC 100$e or $4) do
not replace the infinite variety of possible statements of
responsibility. That transcribed statement of responsibility is
needed, regardless of Mr. Jones being in prime entry as a non-literal
value, with granularity allowing one to display "Tom Jones" in direct
order.
Lubetzky notwithstanding, some redundancy is built into what we do.
__ __ J. McRee (Mac) Elrod ([EMAIL PROTECTED])
{__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
___} |__ \__________________________________________________________
--
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu
