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

[dr-shorthair]

I think this will require a matching change to the TTL representation
https://github.com/w3c/dxwg/blob/gh-pages/dcat/rdf/dcat3.ttl#L1554

[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

[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.