Unique article ID and interface for specifying it

etiennesky
In my opinion Zotero lacks a standard for uniquely identifying a bibliographic entry.

There are 2 contexts (that I know of) where an article ID is used somehow

1) renaming of automatically-downloaded PDF from site translators, the file gets renamed to [Author] - [Year] [Title]

2) export to bibtex, the citation key is set to [author][title][Year]


It would be great that the SAME identifier be used across Zotero.
What would be even better would be
1) Allow the id template to be customizable. I prefer Author_Year{a} it is compact
2) Allow the user to change the ID in the Info tab of the entry editor

The ID would be mapped as a zotero variable, to be used automatically in any context.

The difficulty with this is conflict resolution, perhaps when the item is imported, check the database and then simply add a letter (a,b,c) to the end of the id?

See
http://forums.zotero.org/discussion/31/bibtex-export/
http://forums.zotero.org/discussion/4331/bibtex-importexport-problems/#Item_17
http://forums.zotero.org/discussion/4007/onenote-support/#Item_6
  • noksagt
    edited June 4, 2009
    In my opinion Zotero lacks a standard for uniquely identifying a bibliographic entry.
    That is not true precisely--the word processor plugins and the sync mechanism do use unique ids. However, it is true that local/human-readable IDs can be improved.
    There are 2 contexts (that I know of) where an article ID is used somehow.
    Because a bibliographic item may have multiple attachments, I disagree that the PDF's should necessarily be the same as the item that it is attached to. In the Zotero 2.0 beta, local IDs are also used for RTF scan. Non-human-readable/globally unique IDs can continue to be used in most other places.

    As you are aware, multiple people have already requested to customize and/or view and/or have easier access to local identifiers for working with BibTeX/RTF/etc.
  • etiennesky
    What I meant was a human readable ID that would be consistent across files outside of Zotero (such as PDFs and exported files such as bibtex)


    I agree that a bibliographic item can have more than one item attached, however it is VERY handy to have an easy-to-remember ID for the main item (i.e. the article PDF) so everything is unified.

    The way that things are done now, I'll stop attaching files and keep them in a separate directory (as I always have), so that I can access them outside of Zotero. If the filename was customizable, I would keep them in Zotero.

    Just curious--- are there plans to address the customization/viewing of local ID in 2.0 final?

    thanks!
  • bdarcus
    If you read through in particular my responses on those thread, you'll see this is not as simple as you and everyone else assume. You say "unique id", for example, and I ask "unique in what context?" Is it globally unique, or only to a user? What about groups?
  • noksagt
    If the filename was customizable, I would keep them in Zotero.
    It is customizable, through hidden pref extensions.zotero.attachmentRenameFormatString.
  • noksagt
    You say "unique id", for example, and I ask "unique in what context?" Is it globally unique, or only to a user? What about groups?
    I believe that almost everyone has asked for the features in the context of making them unique for individual authors. I'm sure that when it is implemented, some corner cases will come up where groups will want to keep them the same for a paper they are collaborating on, though.

    Quite frankly, I think that people would be much happier with only incremental improvements to local IDs (because no other product has any "perfect" solution (and there probably isn't one)). If IDs that were local to the user were customizable, I don't think they'd even have to be forcibly kept unique (users who customized them are expected to keep track of this in 99% of the software out there). Then everyone can keep referring to their references the way they have grown used to, which seems to be the real driver behind this perennial request.
  • etiennesky
    1)
    Thanks for the hidden pref!

    Perhaps the same should be done for setting a default local id (i.e. a hidden localIDFormatString pref) ?

    2)
    I agree with your point, users are prone to lazyness in changing their ways!
    Indeed enforcing group-level uniqueness is a tough question.
    Why not implement user-editable, local IDs without enforcing uniqueness, and then later work around problems with uniqueness based on user input/problems?
  • bdarcus
    Yes; the way I've been thinking about it for awhile is that these are user-specific. Was just now playing with some code that illustrates:

    >>> print(mylibrary.items[0].label)
    "doe99"
    >>> print(mylibrary.items[0].resource.title)
    "The Title"
    That seems to get what we need.

    I also think that Zotero needs to do a better job throughout distinguishing user data from other (generic) data.
  • etiennesky
    1)
    If I understand correctly, the itemFields.label variable could store that information and that would not cause any conflicts.

    I have looked around at some translators and not found any that uses that variable, am I correct?

    2)
    How does one make a field (i.e. label) available for editing in the "Info" tab? I'd like to know how to do this from a plugin.

    3)
    I was thinking of implementing a firefox plugin based on zotfile which would allow for editing and auto-generating of the "label" field, based on the options and logic used in the zotfile plugin. That logic is much more flexible than using the hidden pref extensions.zotero.attachmentRenameFormatString .
    From thereon, other things like zotfile plugin and bibtex export could use the "label" field.
  • noksagt
    If I understand correctly, the itemFields.label variable could store that information and that would not cause any conflicts.
    At this time, there is no 'label' that is intended to be used as a local identifier. There is a 'label' in the schema, but it refers to an audio recording's publisher. Bruce's proposal would need a new field.
  • etiennesky
    I guess this will take some time then... Any idea if this is planned for 2.0 and an approximate time-frame?

    If not then I'll look into making a plugin, using the "Extra" field as a variable (using id=<article_id> within the Extra field). That isn't great but what else could I use without modifying the Zotero core?
  • SiGi
    Hi etiennesky,

    I have/had the same problem since I use zotero. I also missed a possibility to combine a zotero database entry with a local user specific ID.
    ( See http://forums.zotero.org/discussion/1039/common-fields-for-all-entry-items/#Item_1 , http://forums.zotero.org/discussion/1048/missing-fields/#Item_8 )

    Because I'm missing several fields, I didn't used the "Extra" field, but coded my user-specific information into "special user" notes as a workaround, like
    [Key] Buchmann:2007 -- acts as a bibtex-key
    [Owner] SiGi -- hold's the owner of an zotero entry (perhaps important if one works in groups, but want preserve the local owner of an entry)
    [Location] AllPapers2007 -- acts as a reference to an "physically" existend folder, where I can find the paper.
    ...

    Using the [] this special notes are easy to search. They are exported like other notes,...

    For me, this workaround works fine and I have not to modify the zotero core.
Sign In or Register to comment.