Sort by author year is probably wrong

[denismaier]

https://github.com/jjmccollum/context-sbl/blob/383212620bc8ffcfb70b6fa50f5b916261db11b5/tex/publ-imp-sbl.mkvi#L52

I don't think that's correct. As SBL is based on Chicago the reference list should be sorted by author title.

[jjmccollum]

I actually copied this line from publ-imp-chicago.mkvi:

% The Chicago style sorts the unnumbered rendered list by authoryear

\definebtxrendering
  [chicago]
  [\c!specification=chicago,
   \c!sorttype=authoryear,
   \c!numbering=\v!no]

So if Chicago is supposed to sort by author, then title, then those lines should also be changed.

That said, if SBL is supposed to be sorted by author, then title, then a new authortitle sorttype will have to be defined, since simply specifying \c!sorttype=authortitle doesn't work. I'll have to see where this change would need to be made and e-mail Hans about it, as it would likely be a change he'd want to include in an update. (This is what happened when we introduced the invertedfirst authorconversion.)

[denismaier]

Yes, Ive seen that. But Chicago specifies two formats. 1. Notes and bibliography, and 2. Author-date. The author date system sorts by date. I think the Chicago style that comes with context supports the author date system.

[jjmccollum]

Yes, I'm pretty sure the authoryear sorttype was invented specifically for the Chicago rendering. The trouble is, I can't find where the sorter associated with it is actually defined. In publ-ini.lua, it should be set in the following lines:

function lists.prepareentries(dataset)
        local rendering = renderings[dataset]
        ...
        local sorttype  = rendering.sorttype or v_default
        ...
        local sorter    = lists.sorters[sorttype]

The lists.sorters dictionary, in turn, is populated in publ-sor.lua:

local sorters = { }

sorters[v_short] = function(dataset,rendering,list) -- should we store it
...
end

sorters[v_dataset] = function(dataset,rendering,list) -- dataset index
...
end

sorters[v_list] = function(dataset,rendering,list) -- list index (normally redundant)
...
end

sorters[v_reference] = function(dataset,rendering,list) -- tag
...
end

sorters[v_used] = function(dataset,rendering,list) -- tag
...
end

sorters[v_default] = sorters[v_list]
sorters[""]        = sorters[v_list]
sorters[v_cite]    = sorters[v_list]
sorters[v_index]   = sorters[v_dataset]
...
publications.lists.sorters = sorters

But there isn't anything like sorters["authoryear"]. So perhaps it's defined somewhere else?

[jjmccollum]

Actually, it looks like this one is hidden away in publ-aut.lua:

publications.sortmethods.authoryear = {
    sequence = {
     -- { field = "key",     default = "ZZZZ", unknown = "ZZZZ" },
        { field = "author",  default = "",     unknown = "" },
        { field = "year",    default = "9998", unknown = "9999" },
     -- { field = "suffix",  default = " ",    unknown = " " },
        { field = "month",   default = "13",   unknown = "14" },
        { field = "day",     default = "32",   unknown = "33" },
        { field = "journal", default = "",     unknown = "" },
        { field = "volume",  default = "",     unknown = "" },
     -- { field = "number",  default = "",     unknown = "" },
        { field = "pages",   default = "",     unknown = "" },
        { field = "title",   default = "",     unknown = "" },
        { field = "index",   default = "",     unknown = "" },
    },
}

And this could be getting used in publ-sor.lua in the following lines:

local sharedmethods      = { }
publications.sortmethods = sharedmethods

local function sortsequence(dataset,list,sorttype)
    ...
    local specification = publications.currentspecification
    ...
    local sortmethods   = specification.sortmethods
    local method        = sortmethods and sortmethods[sorttype] or sharedmethods[sorttype]
    local sequence      = method and method.sequence

[jjmccollum]

Okay, I have authortitle sorting working. I just had to add the following lines to publ-aut.lua:

publications.sortmethods.authortitle = {
    sequence = {
        { field = "author",  default = "",     unknown = "" },
        { field = "title",   default = "",     unknown = "" },
        { field = "volume",  default = "9998",     unknown = "9999" },
        { field = "edition",  default = "9998",     unknown = "9999" },
        { field = "index",   default = "",     unknown = "" },
    },
}

I'll send Hans an e-mail asking for this to be included in the next update if it looks good to him. The publ-aut.lua file is not maintained in this repo, and it's probably best not to add it, as it's not strictly a part of the SBL publication support module. I'll be removing the publ-imp-author.mkiv file from this repo in the next commit for this reason (again, Hans plans to include the changes I've made to it in the next update).

[denismaier]

I think it wouldn't hurt having year in there as well of it appears somewhere after title. (The authoryear sorting scheme uses title as well, albeit at the very end...)

[jjmccollum]

That's fair. I universally prefer the full date field to year (and I don't check for month or day at all at this point, which is a feature I probably could implement), so something like this would probably make the most sense:

publications.sortmethods.authortitle = {
    sequence = {
        { field = "author",  default = "",     unknown = "" },
        { field = "title",   default = "",     unknown = "" },
        { field = "volume",  default = "9998",     unknown = "9999" },
        { field = "edition",  default = "9998",     unknown = "9999" },
        { field = "date",  default = "",     unknown = "" }, -- this is a string of format "YYYY-MM-DD"; how can we sort it correctly?
        { field = "year",    default = "9998", unknown = "9999" },
        { field = "month",   default = "13",   unknown = "14" },
        { field = "day",     default = "32",   unknown = "33" },
        { field = "index",   default = "",     unknown = "" },
    },
}

But since date is a string of form YYYY-MM-DD, it may not sort exactly as we'd like...

[jjmccollum]

Then again, we shouldn't have any dates with a year over 9999, and if the format specification is YYYY-MM-DD, then years before 1000 should be expected to be zero-padded, so that should work. I'll use the following sequence:

publications.sortmethods.authortitle = {
    sequence = {
        { field = "author",  default = "",     unknown = "" },
        { field = "title",   default = "",     unknown = "" },
        { field = "volume",  default = "9998",     unknown = "9999" },
        { field = "edition",  default = "9998",     unknown = "9999" },
        -- date is preferred, but fall back on year, month, day
        { field = "date",  default = "9998-13-32",     unknown = "9999-14-33" },
        { field = "year",    default = "9998", unknown = "9999" },
        { field = "month",   default = "13",   unknown = "14" },
        { field = "day",     default = "32",   unknown = "33" },
        { field = "index",   default = "",     unknown = "" },
    },
}

I think we can reasonably expect that two entries with the same author, title, volume, and edition will not differ with one having a date and the other having a year, month, and day.

[denismaier]

Won't date and year add be consolidated into the same internal structure? I would have expected them to be different notations for the same thing.

[jjmccollum]

Oh, right! Yes, date, year, and pubstate (e.g., "forthcoming") are all grouped into a set in publ-imp-sbl.lua:

date = { "date", "year", "pubstate" }, -- prefer the more specific field, and prefer any date to publication state (e.g., "forthcoming")

So they should be compared. In this case, the entry with year would be sorted before the entry with date...but again, if the two entries match up to that point, I'm not sure why they would be included as distinct entries anyway.

[jjmccollum]

In fact, this can be simplified a bit further. The volume (and part) fields don't need to be included in this sequence, as untitled volumes in a multivolume collection should not be cited in the list (only their collections should be). And the edition field is probably not necessary in practice if we use the date fields, since we can probably safely assume that two editions would not be released in the same year. So maybe this would be enough?

publications.sortmethods.authortitle = {
    sequence = {
        { field = "author",  default = "",     unknown = "" },
        { field = "title",   default = "",     unknown = "" },
        { field = "date",  default = "9998-13-32",     unknown = "9999-14-33" }, -- date = {date, year, pubstate}
        { field = "month",   default = "13",   unknown = "14" },
        { field = "day",     default = "32",   unknown = "33" },
        { field = "index",   default = "",     unknown = "" },
    },
}

[denismaier]

The volume (and part) fields don't need to be included in this sequence, as untitled volumes in a multivolume collection should not be cited in the list (only their collections should be).

I'd say better leave it there. Maybe another style will want to use it as well?

[jjmccollum]

Good point. So something like this?

publications.sortmethods.authortitle = {
    sequence = {
        { field = "author",    default = "",           unknown = "" },
        { field = "title",     default = "",           unknown = "" },
        { field = "maintitle", default = "",           unknown = "" }, -- if this is an untitled volume in a multivolume collection
        { field = "volume",    default = "",           unknown = "" },
        { field = "part",      default = "",           unknown = "" },
        { field = "date",      default = "9998-13-32", unknown = "9999-14-33" }, -- some specifications allow date instead of year, month, day
        { field = "year",      default = "9998",       unknown = "9999" },
        { field = "month",     default = "13",         unknown = "14" },
        { field = "day",       default = "32",         unknown = "33" },
        { field = "index",     default = "",           unknown = "" },
    },
}

[jjmccollum]

This shouldn't be relevant to SBL, but it may be worth noting that in order for the volume field to sort properly, its values will have to contain leading zeroes; otherwise, an entry with volume = {2} will be sorted after one with volume = {10}. To accommodate this, specifications would need to remove the leading zeroes when they typeset volume and part numbers.

I realize that I also need to account for categories that may not have their own titles, such as @suppbook and @review. So this might be better:

publications.sortmethods.authortitle = {
    sequence = {
        { field = "author",    default = "",           unknown = "" },
        { field = "title",     default = "",           unknown = "" },
        { field = "booktitle", default = "",           unknown = "" }, -- if this is an untitled section (e.g., introduction, foreword, preface) of a book or a review of a book (todo: define a getter for this if the entry uses a crossref to its book?)
        { field = "maintitle", default = "",           unknown = "" }, -- if this is an untitled volume in a multivolume collection (todo: define a getter for this if the entry uses a crossref to its collection?)
        { field = "volume",    default = "",           unknown = "" },
        { field = "part",      default = "",           unknown = "" },
        { field = "date",      default = "9998-13-32", unknown = "9999-14-33" }, -- some specifications allow date instead of year, month, day
        { field = "year",      default = "9998",       unknown = "9999" },
        { field = "month",     default = "13",         unknown = "14" },
        { field = "day",       default = "32",         unknown = "33" },
        { field = "index",     default = "",           unknown = "" },
    },
}