Although not specifically related to CSL, I was wondering whether
people on this list had opinions about the tools currently available
for creating bibliographic citation styles.
This week I tried the tool available in EndNote X5 and the tool
available from Wizfolio.
Have people on this list tried these tools, what are the strengths and
weaknesses?
What tools represent the state of the art?
MakeBST.
OK, I’m (only partially) joking.
I was an Endnote user way back about 15 years ago, but I honestly
doubt their citation style UI has changed much since then.
Strengths:
They have a style editor that allows users to modify their styles
without too much hassle (much less hassle for non-tech-savvy users
than hand-editing CSL files).
Weaknesses:
In summary, the styles aren’t very good, and they’re tedious to create.
Any editor I’ve seen (save for MakeBST) has adopted this basic
approach: simple type-based templates.
I think the problem with it, aside from what I note above, is that it
forces users to get too far down into the weeds. In this sense, the
approach is too complicated and time consuming.
OTOH, the other limitation is that the styles themselves become too
simple (because complex operations like substitutions become difficult
or impossible to represent).
To put this another way, I’m not aware of any significant evolution in
these UIs: the state-of-the-art is where it was 20 years ago.
But admittedly, I haven’t paid close attention.
My hope is this editor can create (or more likely, to help users find)
better styles more quickly.
Bruce
Apparently Qiqqa recently took a stab at creating a CSL editor. I haven’t
checked it out yet.
https://twitter.com/#!/jimmejardine/status/163287017592070144
Rintze
It’s not WYSIWYG. Similar to Zotero’s.
BTW, one clarification …On Wed, Feb 8, 2012 at 8:28 AM, Bruce D’Arcus <@Bruce_D_Arcus1> wrote:
- type-based approach meant styles were kind of brittle (every type
needed to be fully-specified for formatting to work correctly)
This issue is more apparent to users in the social sciences,
humanities, and law, which typically cite a far wider array of
document types. If you only cite journal articles and books (which
have very regular data as well), then this weakness isn’t as apparent.
But it’s a PITA otherwise.
Bruce
I don’t want to go off-topic, but I think that with CSL 1.0 we sometimes
still need item-type based conditionals. After removing the fallback
behavior we had in CSL 0.8.1, where sub-item types like “report” would also
test true when the test was for “book”, we got stuck with many styles with
conditionals like:
(I took this from http://www.zotero.org/styles/apa)
I don’t see a very easy solution for this, unless we clearly define in CSL
what roles the different item types fulfill, and what fields belong to each
item type. That might make it easier to create conditionals that test on
the presence of certain fields that still work consistently between the
different CSL-supporting apps (Zotero, Mendeley, Papers, etc.). There might
be other ways to improve the situation, but I perceive this issue as one of
the main weaknesses of CSL 1.0.
Rintze
- type-based approach meant styles were kind of brittle (every type
needed to be fully-specified for formatting to work correctly)This issue is more apparent to users in the social sciences,
humanities, and law, which typically cite a far wider array of
document types. If you only cite journal articles and books (which
have very regular data as well), then this weakness isn’t as apparent.But it’s a PITA otherwise.
I don’t want to go off-topic, but I think that with CSL 1.0 we sometimes
still need item-type based conditionals. After removing the fallback
behavior we had in CSL 0.8.1, where sub-item types like “report” would also
test true when the test was for “book”, we got stuck with many styles with
conditionals like:(I took this from http://www.zotero.org/styles/apa)
I don’t see a very easy solution for this, unless we clearly define in CSL
what roles the different item types fulfill, and what fields belong to each
item type. That might make it easier to create conditionals that test on the
presence of certain fields that still work consistently between the
different CSL-supporting apps (Zotero, Mendeley, Papers, etc.).
I have a hunch that one could simplify the above code by testing on
the lack of presence of a certain variable.
My point here is not to argue about whether types are ever needed;
it’s to point out a limitation of requiring types for formatting to
work at all (which is the case in Endnote; it has a “generic” type
template, but then everything else is separate, no code reuse, etc.).
There might
be other ways to improve the situation, but I perceive this issue as one of
the main weaknesses of CSL 1.0.
Exactly what is the weakness though? That we removed fallback behavior
and thus require this? If that’s the case, then it’s easy enough to
recreate fallback logic using variables. The design of fallback
behavior basically said:
if container-title, then:
if publisher, then:
type = chapter
else
type = article
else:
type = book
Easy enough to represent in CSL 1.0.
Bruce
Sebastian, do you have any thoughts on this? Speaking for myself, I
currently have no clue which item types have which fields available. The
only way to find out would be to check every CSL-compatible app for their
implementation, which would be a lot of work, and there are known cases
whether different apps having different mappings/fields. Things would be
much clearer if the CSL project would define the rules here.
Rintze
I have nothing on Ian’s question - the only style editor I ever used
was for Biblioscape and that only had prefixes and suffixes and it
took forever to write a style.
As for testing for item types - I’m not willing to go without. I think
there are many cases where it’s somewhere between hard to impossible
to do that (e.g. dealing with volume #s or page labels), especially if
we want to deal correctly with incomplete date (think e.g. a chapter
that doesn’t have a publisher). But there’s a difference between using
some type-based testing and only using type-based testing. I took
Bruce to object to the latter and I completely agree with that.
That said, we should standardize variables for item types, but that’s
a topic for a different thread.
S.
That’s exactly how I feel about things as well.
Rintze
One of the reasons I started this thread is that in thinking about
creating an editor one of the biggest use cases we have is from users
who say
"I want to be able to edit a style, just like in x" where x is often endnote.
I’ve been unimpressed with the editors available, and I think that
speaks to the complexity of the task.
One of the reasons I started this thread is that in thinking about
creating an editor one of the biggest use cases we have is from users
who say
“I want to be able to edit a style, just like in x” where x is often
endnote.
I know this is what users say. But I don’t think it’s what they really
mean. The “edit the style just like x” is merely one solution to their real
problem, which is to get correct output as specified by their style. E.g.
one upshot is that the best “style editor” would recognize the style you
need is already written.
I’ve been unimpressed with the editors available, and I think that
speaks to the complexity of the task.
True.
BruceOn Feb 14, 2012 5:26 AM, “Ian Mulvany” <@Ian_Mulvany> wrote:
- Ian
On 8 February 2012 16:58, Rintze Zelle <@Rintze_Zelle> wrote:
On Wed, Feb 8, 2012 at 11:43 AM, Sebastian Karcher > > <@Sebastian_Karcher> wrote:
As for testing for item types - I’m not willing to go without. I think
there are many cases where it’s somewhere between hard to impossible
to do that (e.g. dealing with volume #s or page labels), especially if
we want to deal correctly with incomplete date (think e.g. a chapter
that doesn’t have a publisher). But there’s a difference between using
some type-based testing and only using type-based testing. I took
Bruce to object to the latter and I completely agree with that.That said, we should standardize variables for item types, but that’s
a topic for a different thread.That’s exactly how I feel about things as well.
Rintze
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
Best Open Source Mac Front-Ends 2023
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
xbiblio-devel List Signup and Options–
Ian Mulvany | VP Product
http://www.mendeley.com/profiles/ian-mulvany/Mendeley Limited | London, UK | www.mendeley.com
Registered in England and Wales | Company Number 6419015