search

relaton / relaton-py

Python library for Relaton
MIT License
1 stars 1 forks source link

Add LocalityStack model to accommodate more DOI data from Crossref #18

Closed stefanomunarini closed 2 years ago

stefanomunarini commented 2 years ago

As for https://github.com/ietf-ribose/bibxml-service/issues/209 , we want to accommodate more DOI data obtained from the Crossref APIs to match the data returned by doi2ietf-py.

The current implementation does not include data such as volume, page and journal-issue. This data is returned by the Crossref APIs, but it is currently ignored by our service.

As for LutaML and RNC specifications, this data can be accommodated creating a LocalityStack model linked to BibliographicItem.

On the other hand, additional data such as issued-date (as seen in doi2ietf-py implementation), can be accommodated in the BibliographicItem model without the need of creating additional models or fields, by simply using the already existing BibliographicItem date field which accepts a variety of different date types.

strogonoff commented 2 years ago

@ronaldtse I think you’ve seen it already, but to clarify what’s going on here: doi2ietf-py (doilit) used to convert some DOI data into xml2rfc format that we currently ignore. We want to include that data in XML, to avoid this being a regression from doilit. However, since we use Relaton as core format, to achieve this we need to expand Relaton model coverage in Python to include relevant data points first. After this, we can update 1) DOI/Crossref integration (currently in BibXML service, but I think we should split it out into a helper package) and 2) BibXML serializer (part of this repository) so that both make use of those model properties.

strogonoff commented 2 years ago

(Related: https://github.com/ietf-ribose/bibxml-service/issues/209)

stefanomunarini commented 2 years ago

The LutaML defines different proxy models between BibliographicItem and BibItemLocality.

In particular:

  1. BibliographicItem defines an extent field which references locality* | localityStack*.

  2. localityStack references locality.

  3. locality finally references the BibItemLocality.

I was wondering how stable are the LutaML specs and if it makes sense to have these proxy models here. @strogonoff @ronaldtse

The alternative would be to reference BibItemLocality directly from the BibliographicItem models, like:

BibliographicItem.extent = List[BibItemLocality]
strogonoff commented 2 years ago

@stefanomunarini, Nick (@opoudjis) says these parts of the spec may be awkward to maintain backwards compatibility.

What I think we should do is probably this: