On Sat, 2004-10-30 at 09:51, Andrew E Switala wrote:
> In keeping the metadata close to the citation, as with unparsed lists of
> authors and part information, wouldn't we lose the ability to transform
> the data?  Consider, e.g., a list of four authors + et al. in the XML
> record, when the desired output style requires three authors + et al. Or
> unparsed part information like "4(3 suppl 2)" when the output style
> requires volume numbers, but not issue numbers, to appear in boldface.
> The elements will ultimately have to be parsed; although the original
> citation could be preserved in <recordOrigin>.

There's a difference between allowing the data to be kept at a highly
granular level and REQUIRING that the data be kept that way. I think
that should depend on the application and the purposes of the metadata.
I also think that in any algorithm that is parsing text you have a
certain percentage of items that you simply cannot parse correctly, and
thus a "bucket" field is almost always needed. Otherwise you either end
up discarding data that doesn't fit, or you put it in the "wrong" field.
Again, I want the data elements to carry the correct data, and
"ogodwhoknows" is a valid data element in my universe.

>
> A question with respect to the et al. issue: If all you had were a
> secondary source with a partial list of authors, and no access to the
> primary source, what would be the best way to encode that in MODS?
> Maybe link to a "special" record in the name authority file for "et
> al."?  I haven't found myself in that position yet, but it's bound to
> happen someday.

There isn't any coding that I know of for et al, because it only makes
sense when you have a list of authors, not individual authors. It means
"this list continues, but we didn't write all of the names in our
metadata." Unlike "anonymous", which replaces a single author, et al
doesn't stand alone. When I was doing transformations of citations for
the University of California library systems, we created a special case
author for et al. We considered adding it to the third author's element,
but instead did:
  author1 smith
  author2 jones
  author3 doe
  author list suffix et al

We didn't call it author list suffix but it had specific coding so
that's all it could be.

Note also that for citations, the order of author names can be
important, not just that "et al" needs to be the last thing displayed.
There is often a concept of "first author listed" and some citation
indexes only record that author or give that author a special coding.
The first author then can be key to finding a citation, so order of
authors must be maintained.

kc
>
> --Andy
>
> >>> [log in to unmask] 2004-10-30 11:38:14 >>>
> On Fri, 2004-10-29 at 19:03, Bruce D'Arcus wrote:
>
>
> > If you have any specific thoughts Karen, let me know.
>
> Well, I know that it would be a great deal of work, but I really think
> we need a "citation" format -- something that is loose enough to carry
> the data from the wide variety of citation styles (and non-styles ;-).
> Depending on your need, you could use multiple fields for multiple
> authors
>   <creator> Jones </creator>
>   <creator> Smith </creator>
>   <creator> Doe </creator>
>
> Or you could have an author statement like those seen in many
> citations:
>   <creatorList>Jones; Smith; Doe; et al</creatorList>
>
> At least in this way you know what you have, and you don't have to
> parse
> the field into separate names if you don't have that need. (Because
> parsing always adds a risk of error or loss, i.e. what do you do with
> that "et al" in MODS? yet it carries information.)
>
> And a citation format would have similar ways to encode the volume,
> number and other designations for serials -- separately, if that's
> available, or as a general statement, if that's all that the citation
> provides. Again, the point is that you want your data elements to be
> "true" to the data in them -- you want to know if the "volume number"
> is
> just the number or if it has the caption ("v.3"). You want to know if
> you have just the first page number (which is all many indexing
> services
> give you), if you have the first and last, or if you have the number
> of
> pages (which is included in some services).
>
> I always get nervous about shoe-horning one set of metadata into
> another
> because the meaning of the data elements and what's in them gets
> fuzzy,
> and that makes it hard to do elegant programming. You lose information
> about what your data looks like and what it represents. I don't feel
> that data has to be perfect; I do want the data and the data elements
> to
> be in sync.
> --
> -------------------------------------
> Karen Coyle
> Digital Library Specialist
> http://www.kcoyle.net
> Ph: 510-540-7596 Fax: 510-848-3913
> --------------------------------------
--
-------------------------------------
Karen Coyle
Digital Library Specialist
http://www.kcoyle.net
Ph: 510-540-7596 Fax: 510-848-3913
--------------------------------------