LISTSERV mailing list manager LISTSERV 16.0

Help for MODS Archives


MODS Archives

MODS Archives


MODS@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Monospaced Font

LISTSERV Archives

LISTSERV Archives

MODS Home

MODS Home

MODS  November 2005

MODS November 2005

Subject:

Re: Citation needs. Was: alternate personal names in MODS?

From:

Bruce D'Arcus <[log in to unmask]>

Reply-To:

Metadata Object Description Schema List <[log in to unmask]>

Date:

Wed, 23 Nov 2005 14:26:16 -0500

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (100 lines)

On 11/23/05, Karen Coyle <[log in to unmask]> wrote:

> >Likewise, if I cite a German language journal article in an English
> >text, the citation uses the standards of the English language citation
> >style. E.g. what on the original journal would be one word (my German
> >is terrible, so I don't remember what it'd be!) would in the Eingliish
> >citation be another.
> >
> >
> And if your metadata is being used by someone in Germany?

No problem.

> We also need to internationalize our metadata -- it will be used outside of the US,
> as both MARC and MODS are. We aren't just trying to solve the problem of
> English language citations.

No, and I never presumed we are. But when we deal with markup, we
deal with language. And RDF has the capacity to add language-based
reasoning anyway. So what is tagged in XML "issue" can in the schema
include alternate language descriptions of what that term means, how
it relates to other concepts, etc. I'd venture to say Arabic or
Chinese language journals have concepts of voluem and issue.

> >Right, except my argument would be order is not relevant per se, and
> >actually confuses the issue (um, no pun intended). If the "part"
> >above is a different kind of part than is used in other contexts, then
> >they should just have different names.
> >
> Order matters in systems that will link an article citation in one
> system with the same article in another, such as databases of full text.
> The convention is to cite the parts in hierarchical order for that
> linking; captions are generally not retained nor are they relevant. So
> if one journal has part and then number, and another has number and then
> part, that order will make a difference in terms of linking between
> systems.

OK, I ithnk I see your concern.

But is this not just one solution to a real problem?

The group of publishing and journal database people I've been talking
to have been talking about this same issue recently. How do you
equate two or more article ecords? Never in that discussion has the
issue of volume/issue number come up as a way to draw those
connections. That conversation has always revolved around
identifiers, both uri and otherwise.

> Bruce, you have a very specific application, but yours is only a subset
> of the many uses of journal article metadata. I believe that my proposed
> data elements will allow your application to work, and will also serve
> applications in other environments. We are working on a big picture
> here, bigger, at least, than your application. When others claim to have
> specific needs, we have to try to accommodate them all. I think we are
> working in that direction, trying to move beyond just serving library
> systems. But the solution has to be broad, not narrow.

What is broad and what is narrow is in the eye of the beholder. I
could say the same thing about library practices.

My perspective is not based on one application. It is based on a much
broader perspective that is shaped by my experience as a publishing
scholar, and therefore as someone who works with journal editors, book
publishers, etc., and who interacts with other scholars. It is also
based on talkikng to and working with not just the librarians on this
list (who I have learned a lot from!), but also with people in the
journal publshing and database worlds, with differnt kinds of
applications developers, and so forth.

As a practical point, I think it would be virtually impossible for you
or I to convince the DC community, or PRISM, or Adobe, or the
OpenDocument group, or journal publishers to adopt what you are
advocating. It means more training, more complex files, more complex
schemas, and potentially too more complex GUI interfaces.

I'll give you a really concrete example:

This group I've been working with has tended to want to gravitate
towards using PRISM and DC for their metadata. That group has
recognized they want a structure to represent items below the leve of
the issue; articles. I have had to lobby hard for people to consider