78 lines
2.9 KiB
Markdown
78 lines
2.9 KiB
Markdown
---
|
|
parent: Decision Records
|
|
nav_order: 19
|
|
---
|
|
# Implement special fields as separate fields
|
|
|
|
## Context and Problem Statement
|
|
|
|
How to implement special fields in BibTeX databases?
|
|
|
|
## Considered Options
|
|
|
|
* Special fields as separate fields
|
|
* Special fields as keywords
|
|
* Special fields as values of a special field
|
|
* Special fields as sub-feature of groups
|
|
|
|
## Decision Outcome
|
|
|
|
Chosen option: "Special fields as separate fields", because comes out best (see below)
|
|
|
|
## Pros and Cons of the Options
|
|
|
|
### Special fields as separate fields
|
|
|
|
Example:
|
|
|
|
```bibtex
|
|
priority = {prio1},
|
|
printed = {true},
|
|
readstatus = {true},
|
|
```
|
|
|
|
* Good, because groups are another view to fields
|
|
* Good, because a special field leads to a special rendering
|
|
* Good, because groups pull information from the main table
|
|
* Good, because hard-coding presets is easier than generic configuration
|
|
* Good, because direct inclusion in main table
|
|
* Good, because groups are shown with color bars in the main table
|
|
* Good, because there are no “hidden groups” in JabRef
|
|
* Good, because can be easily removed (e.g., by a formatter)
|
|
* Good, because prepares future power of JabRef to make field properties configurable
|
|
* Bad, because bloats BibTeX file
|
|
* Bad, because requires more writing when editing BibTeX manually by hand
|
|
|
|
### Special fields as keywords
|
|
|
|
Example:
|
|
|
|
```bibtex
|
|
keywords = {prio1, printed, read}
|
|
```
|
|
|
|
* Good, because does not bloat the BibTeX file. Typically, 50% of the lines are special fields
|
|
* Good, because the user can easily assign a special field. E.g, typing “, prio1” into keywords instead of “`\n priority = {prio1},`”
|
|
* Bad, because they need to be synchronized to fields (because otherwise, the maintable cannot render it)
|
|
* Bad, because keywords are related to the actual content
|
|
* Bad, because some users want to keep publisher keywords
|
|
|
|
### Special fields as values of a special field
|
|
|
|
Example:
|
|
|
|
```bibtex
|
|
jabrefspecial = {prio1, printed, red}
|
|
```
|
|
|
|
* Good, because typing effort
|
|
* Bad, because handling in table gets complicated → one field is now multiple columns
|
|
|
|
### Special fields as sub-feature of groups
|
|
|
|
* Good, because one concept rules them all
|
|
* Good, because groups already provide [explicit handling of certain cases](https://docs.jabref.org/finding-sorting-and-cleaning-entries/groups#types-of-groups): groups based on keywords and groups based on author's last names
|
|
* Bad, because main table implementation changes: Currently, each column in the main table represents a field. The main may [mark entries belonging to certain groups](https://docs.jabref.org/finding-sorting-and-cleaning-entries/groups#group-color-bars-in-the-entry-table), but does offer an explicit rendering of groups
|
|
* Bad, because groups are more a query on data of the entries instead of explicitly assigning entries to a group
|
|
* Bad, because explicit assignment and unassigment to a group is not supported by the main table
|