schemas missing "format": "uri"

[jmcanterafonseca-iota]

Bug Report

For several fields in the JSON Schema it should be added "format": "uri". For instance, distribution.format , accessService.endpointURL and might be others.

[arnoweiss]

This would be a non-backward compatible change. Would you elaborate on the motivation?

[jmcanterafonseca-iota]

mmmm why is it a non-backward compatible change?

if it were it would mean that existing implementations are completely broken, and I hope it is not the case ...

[arnoweiss]

uri is a subset of string. If an implementation complies with DSP 2025-1, endpointURL may be a non-uri-string. If we were to limit endpointURL to uri in a future release, that would be incompatible because something that was allowed previously would be forbidden in the next release.

That's why I'm specifically asking why these properties should be restricted to contain only uris.

[jmcanterafonseca-iota]

well, according to W3C DCAT v3 they should be ...

https://www.w3.org/TR/vocab-dcat-3/#Property:data_service_endpoint_url
https://www.w3.org/TR/vocab-dcat-3/#Property:distribution_format

[arnoweiss]

uri in json schema is narrower than IRI according to RFC 3987. So introducing that wouldn't even satisfy the dcat3 spec. string encompasses all identifiers so I still consider it to be a more appropriate choice.

[jmcanterafonseca-iota]

is an empty string a valid one? because if it is not then string alone seems not to be an appropriate choice either ...

I can accept that the "official" Schemas are not fully accurate but the spec, if it aspires to be robust (I remember the pre-HTML5 days where browser specs were so flaky that no one could develop a Web App that worked on several browsers) should clearly specify the set of possible values. Then implementers can decide if they want to implement them with your or their schemas but the spec must be clear.

[SimonStier]

uri is indeed too narrow, but JSON Schema also has iri (RFC 3987, absolute), which is what DCAT 3 asks for. iri-reference would be wrong here, since an endpoint URL should not be relative. And format is annotation-only in 2019-09 unless the Format-Assertion vocabulary is in use, so adding it forbids nothing that validates today.

A format keyword alone will not make endpointURL conform, though. The context maps it as "endpointURL": "dcat:endpointURL" without IRI coercion, so it expands to a literal where DCAT 3 wants an IRI. {"@id": "dcat:endpointURL", "@type": "@id"} fixes that and changes no serialized JSON.

For distribution.format neither helps: it is "@type": "@vocab" with no @vocab defined, so expanding and compacting the official catalog.json turns "HttpData-PULL" into a document-base-relative IRI. leftOperand behaves the same way.

Also worth noting that no format value separates a compact IRI from an absolute one, since odrl:use is a valid absolute IRI whose scheme is odrl. That check belongs to the context.