XSD gYear literals are represented as dates

[wxwilcke]

When creating or reading literals with XSD's gYear as datatype, these get stored as Python's datatime.date. While I can understand the choice for this approach, it nevertheless changes the semantics of the literals and incorrectly increases their precision by specifying a month and day.

To reproduce:

> import rdflib
RDFLib Version: 5.0.0
> gyear = rdflib.Literal("1970", datatype=rdflib.XSD.gYear)
> gyear.toPython()
datetime.date(1970, 1, 1)
> str(gyear)
'1970-01-01'

The above representation causes several problems. Firstly, when decoupling the values from the Literal class, e.g. using gyear.toPython(), str(gyear), or gyear.value, it is no longer possible to discern that the value is of datatype year, and that the month and day representations are meaningless. Secondly, when serializing the graph, the month and day representation are included in the literal, which therefore violate the definition of the value space:

gYear uses the date/timeSevenPropertyModel, with ·month·, ·day·, ·hour·, ·minute·, and ·second· required to be absent [1].

This serialization problem is an oversight I assume, and can easily be remedied by returning only the year representation when the datatype is gYear. The other issue is a bit more challenging, since I assume you want to keep the convenience of Python's datetime module. Perhaps it would be an idea to only return a datetime.date object if object.toPython is called, and to return just the year when str(object) or object.value are used.

[1] https://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/datatypes.html#gYear

[aucampia]

Firstly, when decoupling the values from the Literal class, e.g. using gyear.toPython(), str(gyear), or gyear.value, it is no longer possible to discern that the value is of datatype year, and that the month and day representations are meaningless.

Short of creating custom types, which I think would best be avoided if possible, there is little that can really be done about this.

Secondly, when serializing the graph, the month and day representation are included in the literal

This was already fixed in 6.0.0:

# scratch.py
from rdflib.term import Literal
from rdflib import Graph
from rdflib.namespace import Namespace, XSD
import rdflib
import sys
import os

import logging

logging.basicConfig(level=logging.INFO, stream=sys.stderr)


g = Graph()
EG = Namespace("http://example.com/")

logging.info("rdflib.__version__ = %s", rdflib.__version__)

lit = Literal("1970", datatype=XSD.gYear)

logging.info("str(lit) = %s", str(lit))

g.add((EG["entity"], EG["property"], lit))

g.serialize(format="turtle", destination=sys.stdout.buffer)

$ pipx run --spec 'rdflib==5.0.0' python scratch.py 
INFO:root:rdflib.__version__ = 5.0.0
INFO:root:str(lit) = 1970-01-01
@prefix ns1: <http://example.com/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

ns1:entity ns1:property "1970-01-01"^^xsd:gYear .

$ pipx run --spec 'rdflib==6.0.0' python scratch.py 
INFO:root:rdflib.__version__ = 6.0.0
INFO:root:str(lit) = 1970
@prefix ns1: <http://example.com/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

ns1:entity ns1:property "1970"^^xsd:gYear .

[aucampia]

Closing this issue, as I said before, short of creating custom types we cannot really do much and we want to avoid that as much as possible as it is not really useful, additionally the issue you had with RDFLib 5 is fixed in RDFLib 6. If you have further issues please re-open this issue.