`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

[schivmeister]

Since there was no direct response to the question, we assume that these discrepancies are known and their limitations and/or workarounds accepted.

@andreea-pasare @AchillesDougalis is this issue known and recorded in the ePO WG?

[cristianvasquez]

dear @schivmeister

This is not a trivial choice, the data is heterogeneous.

The ePO is used not only for eForms but also to represent other sources. A significant challenge is that member states represent dates in various formats.

We still need a better overview of the data to make an informed decision.

One potential solution could be for the ePO to relax xsd:dateTime to an alternative type that allows both xsd:dateTime and xsd:date.

For the effects of this mapping exercise

xsd:date for legally binding values.

For any other Looking at potential solutions 1 and 3 by @csnyulas , option 3 will raise SHACL validation errors, whereas 1 won't be the true reflection of the input. However, is the time component needed?

this can be answered by looking at the 'Competency questions' this data answers. (ontology team)

[muricna]

For the current mappings we must use what ever is in the eForms even if it gives errors, however a long term solution should be found.