On 1 Jan 2008, at 12:52 AM, James Harrison wrote: > Christiaan- > > Thanks for the response. I've clarified a couple of my points below > and added a few additional comments, but I don't mean to be demanding > about this at all. If these capabilities aren't appropriate for > inclusion in BibDesk, I'll do my best to handle what's needed for an > author-date version of CiteInPages in the script. > > On Dec 31, 2007, at 11:07 AM, Christiaan Hofman wrote: > ... > >> A problem of sorting support in templates is that it is 'static': you >> have to hard code the possible sortings, there is no way to pass an >> arbitrary sort key in a template. Also, it would be useless and >> counter intuitive in templates used for export, as it overrides the >> natural order from the items or the table. Having said this, it would >> be possible to make a few sorting mechanisms (such as author search) >> available, as we do in Skim. In fact I just added one. > > I think that the need is mainly for sorting bibliographies by authors > and then by date as a secondary sort, so the number of keys involved > should be limited. For scripts, this could be partly handled using the > table sort, if there was a way within a script to trigger the table to > sort by authors/date prior to extracting bibliographies. However, I > didn't see anything in the BibDesk Applescript dictionary for table > sorting. Author-date bibliographies have a bunch of low-incidence > conditions that can be challenging, though. For example, if there's no > author you want the reference to sort in the bibliography by the first > field, which could be a company name, the title, or something else. To > know what will be first in a particular bibliography, you need the > template--or it's output--which is one reason I thought of doing the > sorting as part of the templating process >
There is currently no AppleScript support for sorting. But I added a new 'sort' AppleScript command that sorts a list of publications (calling the sorting mechanism used by the table). It also allows for a subsort. >>> There are a couple of other edge conditions in author-date citations >>> that turn out to be challenging in an Applescript implementation: >>> >>> 1. When first authors with the same last name and publication year >>> but >>> different first names appear in a bibliography list, the in-text >>> citations should show the initials of both those authors. Citations >>> for the rest of the references should show just the last names as >>> usual. >>> >>> 2. When there are several publications in a year with the same first >>> several authors, the in-text citations and the bibliographies should >>> distinguish those publications by, for example, an "a," "b," "c," >>> and >>> so forth after the year. >>> >> >> That's why a cite key is useful. I'd call it more a problem of the >> approach of not using cite keys. > > I'm not sure I follow. CiteInPages uses cite keys directly as in-text > working citations. In final formatting (after the manuscript is > complete), the cite keys are used to look up references and are > replaced by templated representations of these references for in-text > citations. The bibliography is generated using a second template with > the list of the unique cite keys in the manuscript. There's no problem > targeting the correct references in working citations, in BibDesk or > in the script using cite keys. The problem is that the templated > output doesn't have a way to allow the reader to visually link in-text > citations with the correct references in the bibliography list when > there are overlapping initial author names and years. For example, APA > specifies that in-text citations of references with "colliding" last > names and years should be represented in special ways (1 and 2 in my > previous note above). The template mechanism doesn't appear to cover > these cases at the moment, which is understandable. This is also an > issue that would occur with BibTeX/LaTeX; it must be handled as part > of the overall manuscript formatting process there, working directly > from the bib file. > Templating can never add context sensitive information like an extra 'a', 'b', etc., because the context information is not available. The only contextual information you have to generate a value in a template is the object (like the publication) for which to generate a value. If you want to make the keys unique you either have to generate the keys in your program, or it already must be part of the information present in the publication (like in a cite key). The template can never ever generate it. >>> >>> An alternative might be to address this issue within BibDesk. The >>> complete idea would be to allow a list of publications to be >>> extracted >>> from BibDesk via Applescript in a particular primary and secondary >>> sort order based on existing fields (authors and year, for example). >>> Each publication would also include a templated citation string and >>> bibliography string, based on citation and bibliography templates >>> specified at extraction time. There would be a switch (or template >>> tag) that allowed citation and bibliography strings to include >>> additional designators such as initials or characters after the year >>> to deal with the name conflicts noted above. >>> >> >> As noted above, this is not possible in the templating mechanism. In >> your script, the publications come from the text, so it's not >> something extracted from BibDesk. So I don't really understand what >> you mean here. I don't see anything here that BibDesk could/should >> ever handle. > > > The concept is that a script would read through the text document and > gather a list of the unique cite keys. This list would be passed to > BibDesk en bloc along with template names, and at that point BibDesk > would have everything it needs to deal with the correct representation > of that list of references. BibDesk currently can return a list of > publication objects corresponding to a cite key list. These > publication objects have a styled text attribute that contains a text > representation of its reference that seems to be based on the view > defined for the preview (I may be wrong on that--if so, sorry). A > publication object could have two new attributes similar to styled > text, CitationStyledText and BibliographyStyledText, that contained > the text representations for in-text citations and bibliography > entries, respectively. These attributes would acquire values on > extraction, if appropriate templates were specified, and the values > would not need to be stored by BibDesk. > The styled text representations can be generated using a template. So I don't see what else is there apart from what's already supported, there is no need for separate accessors. > So, extraction of a set of references from a BibDesk library using > Applescript might look something like this: > > set refList to get publications for myCiteKeys using myCitationStyle > for CitationTemplate and using myBibStyle for BibliographyTemplate > sort by BibliographyStyledText > > The returned list publication objects (in refList) would have > individual citation and bibliography text representations in their > corresponding attributes as specified by the templates, including the > use of author initials or extra characters appended to the years when > name/year collisions occurred. For this to work correctly, of course, > you'd need to do the whole reference extract at once after assembling > the cite key list from the document. As you point out, you couldn't do > it piecemeal. In-text citations could then be replaced directly using > cite keys to match to the correct publications and the bibliography > could be built easily by cycling through the list in order. > Again, templates can never add the extra stuff to make keys unique, because it has no access to contextual info. It does not know *what* to make unique, and also not unique compared to what, it is just dumb substitution. > Since the templating system--particularly with the new editor--puts a > lot of power in users' hands I'd prefer not to have to bypass it to > deal with these author-date citation issues. However, I'll certainly > understand if this isn't on the near-term road map for BibDesk and my > comments here are just meant to clarify the initial suggestion. > > Best wishes, > > Jim Harrison > UVa It's not on the road map because it cannot be done, I'm afraid. Christiaan ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bibdesk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-users
