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 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 documents. 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. Bruce