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?

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

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

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

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

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

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

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

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.

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.