xsd:date vs. xsd:dateTime in the mapping of fields BT-536-Lot, BT-537-Lot, BT-78-Lot, BT-719-notice, BT-1451-Contract

[csnyulas]

Several eForms fields provide a date value, while the corresponding ePO property has xsd:dateTime as its range.

This is a problem, since we cannot generate a valid xsd:dateTime value only from a date value (without resorting to adding some artificial time component, which is not present in the input data), and xsd:date and xsd:dateTime have incompatible structure.

There are three potential solutions, each generating a separate problem:

1. Create a valid xsd:dateTime value from a simple date, by adding a fictive time component suffix, such as T00:00:00 or T23:59:59, after the date. This is undesirable since the output will not be a true reflection of the input.
2. In the output use the date value as it appears in the input, but type it xsd:dateTime. This will create an invalid RDF
3. In the output use the date value as it appears in the input, and type it xsd:date. This will create an RDF that will raise SHACL violations against the ePO SHACL shapes.

OP suggested we implement option 3 for now, however the problem will be further discussed and potentially addressed in the ePO WGs.

Here is a list of fields where this problem occurs:

• BT-536-Lot (Duration Start Date)
• BT-537-Lot (Duration End Date)
• BT-78-Lot (Security Clearance Deadline)
• BT-719-notice (Change Procurement Documents Date)
• BT-1451-Contract (WinnerDecisionDate)

and here are the related ePO classes and properties

• epo:Period / epo:hasBeginning
• epo:Period / epo:hasEnd
• epo:SecurityClearanceTerm / epo:hasDeadline
• epo:ChangeInformation / epo:hasProcurementDocumentChangeDate
• epo:AwardDecision / epo:hasAwardDecisionDate

[cristianvasquez]

I understand that using xsd:date or xsd:datetime in the Ontology depends on the legal aspects. Would this be correct @muricna ?

[muricna]

Yes this is correct