XMP Writer incomplete

[suppenkaspar109]

JabRef version

5.5 (latest release)

Operating system

Windows

Details on version and operating system

Win 11

Checked with the latest development build

• I made a backup of my libraries before testing the latest development version.
• I have tested the latest development version and the problem persists

Steps to reproduce the behaviour

1. Create pdf with dummy metadata for each xmp-field (Type, Author, Date, Source, Contributor, Publisher, Subject, Relation, Language, Rights, Coverage, Format, Description)
2. Import this pdf into jabref
3. Change each field entry before writing metadata back to pdffile
4. Write metadata back to pdf file
5. Inspect metadata in pdf viewer

The problem is that not all field are written back to the pdf file.
There are setter/adder function in DublinCoreExtractor.java for the field: DESCRIPTION, IDENTIFIER, TITLE, FORMAT, CONTRIBUTOR, CREATOR, PUBLISHER, SUBJECT, RELATION
The DATE field is not fully converted (only year and month field)

Remaining fields are added as relation to the RELATION-Field (with /bibtex-prefix), however there are setter/adder function provided by pdfbox (in DublinCoreSchema.java):
COVERAGE, LANGUAGE, RIGHTS, SOURCE, TYPE

Please add these missing functions to DublinCoreExtractor.java, so the complete XMP functionality can be used in both ways. If possible fix the DATE transformation, so also the DAY field could be used. Thank you.

Appendix

...

Log File

Paste an excerpt of your log file here

[addak]

Hi
If this issue isn't taken up, could I have a go at it?

[Siedlerchr]

@addak Sure, but I recommend waiting until #8521 is merged to avoid any conflicts. You may however already make yourself familiar with the XMP-Importing.

[addak]

already make yourself familiar with the XMP-Importing

I'm actually a new at this, so yeah, regarding that, is this page sufficient : https://docs.jabref.org/advanced/xmp ? Or are there any additional resources that would be helpful?

[Siedlerchr]

That looks good so far, codewise the classes in org.jabref.logic.xmp are relevant. We also have unit tests for the import/export. So that should give you a good starting point. Otherwise for more advanced questions about XMP @btut might be helpful

[addak]

Hi!
I have a question
So I can see that we have an DublinCoreExtractor.extractType method where it states that Type from both DC & BibTex are the same. Since I'm referring https://www.dublincore.org/specifications/dublin-core/usageguide/2001-04-12/generic/#type for DC type usage and https://www.bibtex.com/f/type-field/ for bibTex Type usage, I can see that it's not the case....
So yeah, do I implement the fillType following the assumption made or according tot he examples above?

Edit : Okay maybe the dublincore link is too old, as wikipedia's description suggests they are equivalent

[Siedlerchr]

Hi, you have to differ between entrytype e.g. article, inproceedings, misc...
and the subfield type for an entrytype like TechReport where type specifies the concrete kind of the report (e.g. research report)

[addak]

Hi!
So While I'm done with the first part
Regarding the date, I was thinking maybe we could use the qualifier property like
<dc:date> <rdf:Seq> <rdf:li xml:format="YYYY">2006</rdf:li> </rdf:Seq> </dc:date>
So that we can somehow store the format. We could , obviously, fallback to the way the date extraction/fill happens now. Currently looking if there's a way to get the format value into DublinCoreExtractor.

[Siedlerchr]

Cool! Regarding dates, this should not be a problem to store incomplete dates (at least according to the spec(
https://www.dublincore.org/specifications/dublin-core/dcmi-terms/terms/date

This refers also a bit to #2753

[addak]

I've created a PR for the issue. @Siedlerchr . Code changes are rough, and could be better. but as far as I understand the issue, I think this ought to be sufficient.

[Siedlerchr]

Thanks, I will take a look when you're ready! Please check any relevant failing tests ( FetcherTests probably not relevant)