Duration gets converted to months

[IS4Code]

Uploading this triple:

@prefix ex: <http://example.org/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

ex:entity ex:val "P18Y3M"^^xsd:duration .

The literal, representing 18 years and 3 months, gets converted when added via Quad Store Upload to "219"^^xsd:duration, which is the same duration but in months. This doesn't seem correct to me, and it doesn't happen for other datatypes. How do I turn it off?

Version 07.20.3230

[TallTed]

@pkleef @HughWilliams @IvanMikhailov @iv-an-ru @openlink

I've quickly recreated the issue on Open Source Edition 07.20.3230 (git head b006ccd) built 2018-12-18 (query form, results) as well as Enterprise Edition 08.03.3315 (git head af87e88746) built 2019-09-26 (query form, results).

[HughWilliams]

@TallTed The issue is not quite the same between VOS and VEE as the former returns "219" and the latter "P219M". And "P219M" is a valid xsd:duration it seems, even if not in exactly the same form loaded. So question for @IvanMikhailov is if VEE value is as intended and if it can be ported to VOS ...

[TallTed]

@HughWilliams /cc @IvanMikhailov

As you say, "P219M" is a valid xsd:duration and "P219M"^^xsd:duration is indeed equivalent to "P18Y3M"^^xsd:duration, but the two values are not equal, and I do not believe that Virtuoso should be changing data values in this way.

So, I see two issues.

1. VEE (now v8.3) should not be changing the data value from "P18Y3M"^^xsd:duration to "P219M"^^xsd:duration (equivalent but not equal).
2. VOS (now v7.2) should not be changing the data value from "P18Y3M"^^xsd:duration to "219"^^xsd:duration (invalid xsd:duration).

[IS4Code]

Any progress on this?

[IS4Code]

I think it would be enough to fix VOS to at least turn P18Y3M into P219M instead of 219 for now. I suppose the reason for this in VEE is efficiency, and I don't find that inherently bad. But it shouldn't corrupt the values like VOS does.

As for the loss of format, I presume all recognized primitive datatypes are affected by this, for example "1"^^xsd:integer, "+1"^^xsd:integer, "01"^^xsd:integer etc. are probably all turned into 1 at the moment. In the past I did some tricks like trying to convert the value to string after parsing it, to see if it matches the assumed format, but again I don't think this is necessary at the moment.

[jakubklimek]

I also ran into related issues.
With the query:

PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
SELECT ?duration WHERE {
  BIND("PT1S"^^xsd:duration AS ?duration)
}

On https://dbpedia.org/sparql (Virtuoso 8) I get:

"1.0"^^<http://www.w3.org/2001/XMLSchema#duration>

which is invalid duration.
On VOS endpoints such as https://data.gov.cz/sparql I get an error:

Virtuoso S0022 Error SQ200: No column PT1SD.

SPARQL query:
define sql:big-data-const 0
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
SELECT ?duration WHERE {
  BIND("PT1S"^^xsd:duration AS ?duration)
}

Actually loading the triple

<http://a> <http://b> "PT1S"^^xsd:duration

into VOS however converts it to "1.0"^^<http://www.w3.org/2001/XMLSchema#duration> as well.

[HughWilliams]

We are looking into the reported issues ...

[mielvds]

@HughWilliams we are working with duration as well and see the issue popping up. Any progress?

[HughWilliams]

This issue is still to be scheduled for looking into by development.

[mielvds]

When would this be scheduled, or is there a way to give this priority? This is a significant data integrity issue; data goes in valid and comes out transformed and invalid.

[mielvds]

To add to the background: the conversion is also not consistent. The value "PT4M57.56S"^^xsd:duration is converted to "297.56"^^xsd:duration (value in seconds), but "PT0.6S"^^xsd:duration is not converted and remains "PT0.6S"^^xsd:duration.

[HughWilliams]

Development should be able to schedule to look into this in the next few weeks, when current tasks are completed ...