We need to decide if we fail validation if a colon is missing, or try to "fix" this for the user and pre-pend the base prefix when a colon does not exist.

Note that we already have validation on the uriorcurie type, but it is less strict than the standard.

According the syntax in the W3C specification, both the prefix and the colon are optional. According the corresponding specs, a string without a colon is at the same time a valid CURIE and a valid relative URI!

CURIEs vs compact URIs

I wonder if LinkML is rather interested in supporting compact URIs (as specified in the JSON-LD v1.1 specification) than CURIEs (as specified in the CURIE spec) and mix them up. What is easy, because they are very similar, but not the same.

Two very important differences (because they help differentiate URIs and what LinkML calls CURIEs) are:

that compact URIs MUST have a prefix and the prefix MUST be listed in the JSON-LD context
that disambiguation is (more or less) clearly specified

Is important to notice that:

compact URIs "shadows" URIs (valid URIs being interpreted as compat URIs instead) in the extremely rare case of an URI with the same scheme as a prefix and with a path that is also a valid compact URI suffix (for example, something like iot:device is at the same time a valid compact URI when iot is in prefixes and a valid URI)
the compact URI spec doesn't clarify what is the syntax of the suffix (could it contain a colon or a slash?)

Therefore IMO "renaming" (changing documentation and code accordingly) from CURIE to compact URI (according the JSON-LD specification) would be the solution with the smallest URI "shadowing" keeping backwards compatibility.

Sticking to CURIEs

Disambiguation of CURIEs

As mentioned in this comment in issue 1400, the only way to avoid the ambiguity between URIs and CURIEs is using characters not allowed in a URI (like it's recommended in the CURIE spec). But I assume that the LinkML wouldn't like this approach.

Any approach accepting both "unsafe" CURIEs and URIs has a bigger or smaller ambiguity.

Migration from "unsafe" CURIEs to "safe" CURIEs

If sticking to CURIEs instead of compact URIs, I see a possibility for a grace migration from "unsafe" to "safe" CURIEs:
Perhaps adding support for safe-CURIEs without rejection of "unsafe" CURIEs (perhaps only a warning) would help migrate to use of

Uh oh!

Need a pure CURIE type #258

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions