Issues with dates: something is appending '-01-01'

[gerontakos]

gYear dates in our RDA/RDF are not outputting to BIBFRAME as gYears.

Dates in RDA/RDF are usually gYear dates: YYYY. Example:
https://api.sinopia.io/resource/9da40fe2-ab05-45b2-90b1-16d80d252e0b a http://rdaregistry.info/Elements/c/C10006 ;
ns2:P20214 "1929"@eng.
...becomes:
https://api.stage.sinopia.io/resource/b535c9fb-e422-46e0-a547-d22755161f6e a bf:Work ;
bf:originDate "1929-01-01"^^xsd:gYear ;
owl:sameAs https://api.sinopia.io/resource/9da40fe2-ab05-45b2-90b1-16d80d252e0b .
That's odd. How does that happen?
That example is an RDA/RDF Expression to BIBFRAME Work-2 transform. We also see this, at least, in RDA/RDF Work to BIBFRAME Work-1 transforms. Also seen in RDA/RDF Manifestation to BIBFRAME Instance. So it looks like it happens across-the-board.

[mcm104]

Turns out this is a known issue that rdflib can't handle gYear and gYearMonth, see:

• xsd:gYear and xsd:gYearMonth error RDFLib/rdflib#747
• problem with parsing "<http://www.w3.org/2001/XMLSchema#gYear>" RDFLib/rdflib#806
• #747 Create new GregorianType class in extras/gregorianType.py to add… RDFLib/rdflib#1073

It looks like some work-arounds have been suggested that are a little over my head, but the issues are all open and it doesn't look like anything is being done about this currently.

This is the issue where we first talked about adding datatypes in the first place: #4 Is having datatypes still a concern? Because a lot of our dates are not conformant to these datatypes (e.g. a lot of years have square brackets around them or copyright symbols), so those are all being treated as regular literals anyway -- is it bad if dates that ARE technically gYear or gYearMonth also go without the datatype? Otherwise, I would propose we only worry about things that are JUST xsd:date and nothing else.

[mcm104]

Code has been edited so that only xsd:date values are typed (link to code). If this is insufficient, we can talk about it at the next meeting.