Address 1536: extend the range of 'spatial resolution'

[pchampin]

The range now allows xsd:double in addition to xsd:decimal. I also added a note in 6.6.5 to explain the rationale of that change.

Should the note be copied in 6.8.13 as well?

Addresses #1536

Preview:

• https://raw.githack.com/w3c/dxwg/issue-1536/dcat/index.html#Property:dataset_spatial_resolution
• https://raw.githack.com/w3c/dxwg/issue-1536/dcat/index.html#Property:distribution_spatial_resolution

Diff:

• https://services.w3.org/htmldiff?doc1=https://w3c.github.io/dxwg/dcat/&doc2=https://raw.githack.com/w3c/dxwg/issue-1536/dcat/index.html#Property:dataset_spatial_resolution
• https://services.w3.org/htmldiff?doc1=https://w3c.github.io/dxwg/dcat/&doc2=https://raw.githack.com/w3c/dxwg/issue-1536/dcat/index.html#Property:distribution_spatial_resolution

[jakubklimek]

Do I understand it correctly, that the idea is that JSON-LD contexts of DCAT and DCAT profiles can choose one of:

1. xsd:double datatype and JSON number representation
2. xsd:decimal datatype and JSON string representation?

[pchampin]

@dr-shorthair

I think this will require a matching change to the TTL representation

Right, but I'm not sure exactly what the process is for this (are some versions generated from others? difference between dcat3. and dcat3-external....) so I would rather leave this to the editors.

[pchampin]

Do I understand it correctly, that the idea is that JSON-LD contexts of DCAT and DCAT profiles can choose one of:

1. xsd:double datatype and JSON number representation
2. xsd:decimal datatype and JSON string representation?

or they can refrain to chose, and leave it to end users... Actually, both options are possible, as demonstrated in [this example](https://json-ld.org/playground/#startTab=tab-nquads&json-ld=%7B%22%40context%22%3A%7B%22rdfs%22%3A%22http%3A%2F%2Fwww.w3.org%2F2000%2F01%2Frdf-schema%23%22%2C%22xsd%22%3A%22http%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23%22%2C%22dcat%22%3A%22http%3A%2F%2Fwww.w3.org%2Fns%2Fdcat%23%22%2C%22spatialResolutionInMeters%22%3A%22dcat%3AspatialResolutionInMeters%22%2C%22spatialResolutionInMetersDouble%22%3A%7B%22%40id%22%3A%22dcat%3AspatialResolutionInMeters%22%2C%22%40type%22%3A%22xsd%3Adouble%22%7D%2C%22spatialResolutionInMetersDecimal%22%3A%7B%22%40id%22%3A%22dcat%3AspatialResolutionInMeters%22%2C%22%40type%22%3A%22xsd%3Adecimal%22%7D%7D%2C%22%40graph%22%3A%5B%7B%22spatialResolutionInMeters%22%3A3.14%2C%22rdfs%3Acomment%22%3A%22this%20will%20produce%20an%20xsd%3Adouble%2C%20which%20is%20now%20correct%22%7D%2C%7B%22spatialResolutionInMeters%22%3A%7B%22%40value%22%3A%223.14%22%2C%22%40type%22%3A%22xsd%3Adecimal%22%7D%2C%22rdfs%3Acomment%22%3A%22this%20will%20produce%20an%20xsd%3Adecimal%2C%20which%20is%20still%20correct%22%7D%2C%7B%22spatialResolutionInMetersDecimal%22%3A%223.14%22%2C%22rdfs%3Acomment%22%3A%22with%20this%20alias%2C%20you%20don't%20neet%20to%20give%20the%20type%20explicitly%2C%20BUT%20you%20MUST%20use%20a%20string%20(otherwise%20an%20invalid%20xsd%3Adecimal%20might%20be%20produced%22%7D%2C%7B%22spatialResolutionInMetersDouble%22%3A%223.14%22%2C%22rdfs%3Acomment%22%3A%22with%20this%20alias%2C%20you%20will%20always%20produce%20an%20xsd%3Adouble%2C%20even%20if%20you%20use%20a%20string%20--%20or%20an%20integer%2C%20for%20that%20matter%22%7D%5D%7D )

[jakubklimek]

@pchampin

or they can refrain to chose, and leave it to end users...

Well, technically, yes. But then the role of JSON-LD in "hiding RDF complexity for JSON users" is somehow diminished if we ask "JSON developers" to choose between

"spatialResolutionInMeters": {
   "@value": "3.14",
   "@type": "xsd:decimal"
}

and

"spatialResolutionInMeters": {
   "@value": 3.14,
   "@type": "xsd:double"
}

for, in JSON world, no apparent reason.

[pchampin]

@jakubklimek Developers that don't want to worry about the underlying RDF will simply use

  "spatialResolutionInMeters": 3.14

and that will be compliant with DCAT, thanks to the proposed change.

Developers who care about those details still have the opportunities to be more precise and use an xsd:decimal.

[jakubklimek]

"spatialResolutionInMeters": 3.14

But this is not that simple. If they go this way, the will probably also use:

"spatialResolutionInMeters": 3

which produces a xsd:integer literal, which, yes, can be converted into xsd:decimal or xsd:double, but strictly speaking, is yet another datatype. That's why it is necessary to state whether the value is a xsd:decimal or xsd:double in the context (one or the other), or in the value.

[pchampin]

@jakubklimek strictly speaking xsd:integer is derived from xsd:decimal (see spec), so having an xsd:integer where an xsd:decimal is perfectly legal semantically. OWL inference engines, for example, will not treat it as a contradiction.

Now, SHACL and ShEX are only concerned with syntax, and a shape requiring xsd:decimal will indeed choke on an xsd:integer value... A pragmatic approach would be for such shape to allow xsd:decimal OR xsd:integer whenever the domain is xsd:decimal. Note that this is an incomplete workaround, because xsd:decimal has many more derived datatype that could semantically be used, but xsd:integer is probably by far the most used.

I have added a comment (bcb5990) explaining this in the note below the definition of dcat:spatialResolutionInMeters.

NB: this issue with xsd:integer is not specific to JSON-LD. The same problem exists with Turtle...

[dr-shorthair]

@andrea-perego can you clarify your position on this?

[dr-shorthair]

It is arguably out of scope for DCAT to address issues in the JSON implementation of RDF. It would be appropriate to add a warning that xsd:decimal is not supported in JSON, but I would be reluctant to add an alternative datatype, as too many choices compromises interoperability.

[riccardoAlbertoni]

I have approved this PR as a consequence of the "rephasing and removing of normative effect" PR #1573 just merged here.

@dr-shorthair @andrea-perego @agbeltran @davebrowning @pwin : Can any of you approve and merge the resulting PR #1543 into the main branch.