Add test for lexical space of xsd:decimal

[ajnelson-nist]

This PR is being filed to try to diagnose an oddity with SHACL validation of some literals typed as xsd:decimal but not being recognized as xsd:decimal. The behavior arose with the release of pySHACL 0.20.0. (A cross-reference will come momentarily, I needed something to track in the pySHACL repo.)

Before merging this PR:

• Resolve runtime error from OWL-RL inferencing.
• Discuss if another test should be added to handle JSON-LD default behaviors.

[ajnelson-nist]

The instigator for this PR was seeing new ValidationResults arise for xsd:decimal values in this patch. From the SHACL validation output, I could not tell what was going on.

When I looked at the JSON-LD being validated, I realized that there is a possibly undefined behavior in the JSON-LD specification. This was getting interpreted by RDFLib as a xsd:double long enough to trigger a ValidationResult, but by the time the pySHACL report-graph was being generated, it was being interpreted as a xsd:decimal:

{
    "@type": "xsd:decimal",
    "@value": 48.860346
}

The patch preventing the default behavior (with spec. citation) is here, and the follow-on patch demonstrating the validation results are undone is the third in this PR.

@nicholascar - is this something that needs to be fixed or clarified in RDFLib's JSON-LD parsing code?

I'm hesitant to augment this xsd:decimal test with a JSON-LD "default behaviors" test until I understand whether this is truly an undefined-behaviors corner-case of the specification.

[ashleysommer]

Hi @ajnelson-nist
In JSON-LD, the lexical value for a Decimal literal must be enclosed in quotation marks.

This structure is ill-typed:

{
    "@type": "xsd:decimal",
    "@value": 48.860346
}

All non-integer numbers in JSON are interpreted by Python as a Float. So when it is read by RDFLib, the discrepency between the @type: xsd:decimal and the @value being a Float, causes the literal to be flagged as Ill-typed.

PySHACL v0.20.0 introduced the feature to check for ill-typed literals, so that is why these errors are now seen when upgrading to that version.

EDIT: I just noticed you have discovered that already, and documented it in this fix here.

To answer your question, the behaviour of RDFLib in this case is correct. RDFlib v6.2.0 has exactly the same behaviour of previous RDFLib versions, except now with the addition that it flags these discrepencies with the Ill-Typed flag, for greater visibility.

[ajnelson-nist]

@ashleysommer Thank you, especially for the part I'd missed, that Python's JSON parser was causing the initial conversion to Float. I'll add a JSON-LD snippet to the test to demonstrate this issue.

Referencing the confusing-looking SHACL validation results again---these were the SHACL validation results from the ill-typed JSON-LD---it looks like this may be a nefarious data issue to explain to users. The Turtle serializes a text snippet that looks, and is, properly typed. I'm guessing it's not possible (or at least not a good idea) to "carry forward" the original ill-typed data into Turtle. Is there anything RDFLib or pySHACL can do to flag this ill typing? I'm guessing flagging would have to happen in the JSON-LD parser.

[ashleysommer]

@ajnelson-nist This has been open a while, and I forget where we got up to. Can it be closed, or does this test need to be revisited?