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?
> 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
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
that it would be better to think more broadly and to get PRISM to
change prism:volume and prism:number to prism:volume, prism:issue and
prism:document (instead of prism:articlleNumber).
And I'm not even sure I've been successful in that! From their
perspecive, all they care about is articles; not other kinds of
Again, what is broad and wha is narrow depends on where one stands.
If we're going to democratize and generalize metadata, it willl --
fortunately or unfortuantely -- have to look a lot more like DC, and a
lot less like MARC (or even MODS). And by "democratize and generalize
metadata," I mean it in just the sort of vision I laid out in
Edmonton. In this world metadata would be distributed (libraries just
being one hub among thousands), and broadly interoperable.