[uf-discuss] Citation format straw proposal on the wiki
ross.singer at library.gatech.edu
Wed Mar 29 04:43:26 PST 2006
To be honest, I wouldn't use the 80/20 rule at all, except that it seems to
be a foundation of the philosophy here.
Also, I hold no bias for or against science based scholars. My current
employer is certainly science focused, but I am not. And libraries have
certainly thought about making access available pretty equally for all
disciplines. Which, in recent history, has been less good. And we can
finally make it good.
But the real point of my reply is not about perceived biases, it's about the
misconception that OpenURL is key value pairs. That is one representation
of OpenURL, but the community profile for journals also has an XML
What, exactly, is lacking (and I'm not saying it's not lacking, but I have
to know what is lacking to work through this problem)? The point here is
that /libraries support this/ and the stuff you're citing /will more than
likely be gotten via a library in some capacity/. If the journal or book
community profiles are severely lacking, I would suggest proposing a new
community profile that /does/ fit your need. But you need to articulate
what your needs are that aren't being met by the existing framework.
Realize, however, that it may take a while for the vendors, publishers and
libraries to support a new profile.
On 3/29/06, Bruce D'Arcus <bdarcus.lists at gmail.com> wrote:
> On 3/28/06, Ross Singer <ross.singer at library.gatech.edu> wrote:
> > On 3/28/06, Bruce D'Arcus <bdarcus.lists at gmail.com> wrote:
> > > I have to disagree on the usefulness of the OpenURL stuff in this
> > Can you explain this? w/r/t HTML, I find OpenURL the /most/ useful in
> > context, with this context being web content and OpenURL being a means
> > link a citation to an appropriate copy/service.
> > In fact, I think if you use the 80/20 rule, your majority of users would
> > /much/ happier finding fulltext for a given citation than the ability to
> > effectively load it into their citation manager.
> Not aimed at you in particular Ross, but I really hate it when people
> trot out the 80/20 rule, whose subtext is always about placing the
> argument of others in the 20 category. And usually when people do it
> in the context of citations, it is people who come from the hard
> sciences telling the humanities people to be quiet (usually in the
> form of "BibTeX is great, why use anything else?").
> So if we do want to talk about 80/20 here, we need to clarify: whose
> 80/20? Do we only create a MF that works for geeks who code their own
> HTML? Or do we consider a more inclusive approach that would be
> appropriate for a broader range of users?
> I'm not dismimssing OpenURL out of hand. Indeed, I added the "in this
> context" qualifier, and certainly one could include OpenURL's (and
> DOI's) within a MF. But I do reject the notion that the existing
> OpenURL journal article schema, for example, provides a good model to
> design a more general microformat. It's just flat key/value pairs,
> which does not scale.
> To me a test of an 80/20 format is can a user/developer reliably and
> consistently encode the following:
> 1. articles (not just journal articles, but also for other periodicals)
> 2. speeches and other presentatiions (like a conference paper)
> The trick is to avoid genre-specific property names like "jtitle" or
> "conference-title" and exploit the nested possibilities of HTML and
> the fact that one can include more than one class attribute.
> But this does get us back to use cases and requirements. By your
> logic, we might not bother with citation text at all. For me, though,
> I want to be able to extract that content in addition to view it. We
> could probably cover both needs though.
> Aside: I typically send my publishers XHTML (generated from DocBook
> and RDF source), so my full citations and bibliographic entries are
> encoded in a microformat at that point. But there I have to conform to
> precise publisher requirements about citation style.
> microformats-discuss mailing list
> microformats-discuss at microformats.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the microformats-discuss