Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

standardise fields and field ordering #31

Closed
cpmpercussion opened this issue Aug 31, 2020 · 7 comments
Closed

standardise fields and field ordering #31

cpmpercussion opened this issue Aug 31, 2020 · 7 comments

Comments

@cpmpercussion
Copy link
Contributor

I've been working with python scripts lately to fix a few bibtex issues in the repo, it would be best to harmonise the field ordering and fields across the proceedings. (otherwise the script just alphabetises everything).

Here's what I've got so far (from 2020)

field_order = ("author","title","pages","booktitle","editor","year","month","publisher","address","issn","url","presentation-video", "abstract")
@alexarje
Copy link
Contributor

Yes, nice. Two things:

  1. If people edit the BibTeX file(s) in some editors (like JabRef), it reorganizes everything according to its own logic. So either we should actively discourage using non-text-based editors for making changes, or we need to run the script once in a while.
  2. There are some more extra fields (as seen in this thread: Urlsuppl1 (2015), Track (2016).

@cpmpercussion
Copy link
Contributor Author

I would like to actively discourage jumping in with JabRef to edit things (not that it's a bad editor).

What I want to avoid is git commits with a whole bunch of different changes (including reordering fields) in addition to the intended fix. This makes it really hard to fix when something goes wrong as you lose all the work by rejecting the commit.

For small fixes, e.g., fixing an author's name a text editor would be fine, for bigger project (e.g., adding DOIs, adjusting fields), I think a scripted solution in python would be much better because the if there are issues with the output, we can revert, edit the procedure and produce the change again.

@cpmpercussion
Copy link
Contributor Author

Just accumulated all the present fields in the proceedings:

['ENTRYTYPE',
 'ID',
 'abstract',
 'abstraction',
 'address',
 'author',
 'booktitle',
 'date',
 'date-modified',
 'doi',
 'editor',
 'isbn',
 'issn',
 'keywords',
 'month',
 'pages',
 'presenation-video',
 'presentation-video',
 'publisher',
 'rating',
 'title',
 'track',
 'url',
 'urlsuppl1',
 'urlsuppl2',
 'urlsuppl3',
 'volume',
 'year']
  • there's obviously a spelling error in a few of the "presentation-video" entries.
  • rating and date-modified look like they would have come from JabRef or BibDesk at some point, so they can probably go.
  • I thought we were always under issn not isbn? Is that from some very early proceedings?
  • abstraction seems like a typo, although it is a bit enigmatic 🙃
  • track is good, we can keep that and maybe extend in future if needed
  • 'urlsuppl1', 'urlsuppl2', 'urlsuppl3': these aren't too bad, but the problem is we don't know what the actual type of file is maybe we should encourage keys with more semantics like "presentation-video", "demo-video", "code-url" or similar.

@cpmpercussion
Copy link
Contributor Author

omg the abstraction typo was in one of my papers 😨

@alexarje
Copy link
Contributor

alexarje commented Sep 1, 2020

Thanks for checking this!

there's obviously a spelling error in a few of the "presentation-video" entries.

Yes.

rating and date-modified look like they would have come from JabRef or BibDesk at some point, so they can probably go.

Yes.

I thought we were always under issn not isbn? Is that from some very early proceedings?

All the proceedings are under one ISSN (which covers the series). Some years the chairs have also set up ISBN(s). Ideally, we should have both to be most compliant will all sorts of library and indexing systems (there is a section in the cookbook about this).

track is good, we can keep that and maybe extend in future if needed

Yes, agree.

'urlsuppl1', 'urlsuppl2', 'urlsuppl3': these aren't too bad, but the problem is we don't know what the actual type of file is maybe we should encourage keys with more semantics like "presentation-video", "demo-video", "code-url" or similar.

Yes, probably easier to parse if we know the data type. The challenge may be that we can end up with a lot of different field names.

@cpmpercussion
Copy link
Contributor Author

Ok, I've fixed the errors and accidental bibdesk/jabref additions.

The only proceedings that has ISBN is 2016, and that year doesn't have the ISSN added. Do you mean that I can safely add the ISSN in addition to the ISBN for 2016?

@alexarje
Copy link
Contributor

alexarje commented Sep 1, 2020

Yes, all years should have the same ISSN, and quite a lot of the years have ISBN. So we should dig those out. I see now that I started a page about this here. Adding a separate issue about ISBN so that we keep track of those.

@alexarje alexarje mentioned this issue Sep 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants