Change definition of type Uri

[nichtich]

The type Uri is underspecified ans misleading. It's description is "a complete URI" so one could assume an absolute URI (no relative URI reference) as defined in RFC 3986 (URI). Then there is a link to http://www.w3.org/2001/XMLSchema#anyURI, referencing xsd:anyURI in XML Schema (2004). What is the normative definition of type Uri in SSSOM?

• a "complete" URI (as defined in RFC 3986)
• any value allowed XML Schema (2004) data type xsd:anyURI
• something else (e.g. IRI)
• ...

Note that xsd:anyURI in XML Schema is more than absolute and relative URIs as defined in RFC 3986 but it also support its own escaping rules to allow more characters.

I would prefer to refer to RFC 3986 with absolute URI in the SSSOM data model only because in the end everything (relative URI, xsd:anyURI, IRI references...) is mapped to an absolute URI. The encoding of URIs in SSSOM/TSV may allow something more, but this needs to be defined more strictly. In theory, xsd:anyURI from xsd:anyURI in XML Schema 1.1 (2012) or RFC 3987 (IRI) could do but they come with several specific rules how to map its value to URI so just referencing these standards will likely not solve the issue unless the underlying specification has carefully been read.

[matentzn]

I agree with the general proposal of further constraining the URI typed slots to be absolute.

@nichtich @gouttegd is the right way to:

Define a new type absolute_uri, which derives its specification from RFC 3986:

types:
  absolute_uri:
    uri: xsd:anyURI
    base: str
    pattern: '^([a-zA-Z][a-zA-Z0-9+.-]*):(?:\\/\\/)?[^\s]*$'

And the use that type like this:

slots:
  license:
    range: absolute_uri
    description: "An absolute URI identifying the license for this mapping set."

[nichtich]

I' prefer to change the definition of type Uri to "an Absolute URI as defined in RFC 3986" and nothing more.

uri: xsd:anyURI
base: str
pattern: '^([a-zA-Z][a-zA-Z0-9+.-]*):(?:\\/\\/)?[^\s]*$'

That's not the same. First xsd:anyURI is problematic because it is not equal to RFC 3986 but it must be mapped to URI, and because the pattern disallows valid absolute URIs without ://. Despite being mentioned, I think that LinkML and definitions of types with YAML should not be normative part of the specification but details of implementation.

[matentzn]

I' prefer to change the definition of type Uri to "an Absolute URI as defined in RFC 3986"

I don't mind referring to the standard but

and nothing more.

I would still like the recommendation to be reflected directly in the spec so we can use standard validation tooling rather than asking tool implementors to read the RFC to figure out what constitutes a valid URI.

First xsd:anyURI is problematic because it is not equal to RFC 3986 but it must be mapped to URI

What I want is to say that the new type here is a subtype of URI, with more constraints. Maybe it should be expressed differently.

I think that LinkML and definitions of types with YAML should not be normative part of the specification but details of implementation.

I don't understand this. The LinkML should provide a full actionable specification of all slots and their ranges. Unless someone has defined the type " RFC_3986:URI" somewhere so I can re-use it, I have to define it myself so I can use standard json schema validation for validating the values.

[gouttegd]

Despite being mentioned, I think that LinkML and definitions of types with YAML should not be normative part of the specification

No. That’s the other way around. For better of for worse (I have some strong opinions about that, which are not relevant here), the LinkML model is the core of the specification – everything else is there to fill the gaps not covered by LinkML.

I would object to any change towards making the LinkML model not normative at least as far as SSSOM 1.x is concerned. If we were to consider such a change, this has to make us jump straight into SSSOM 2.0 territory.

[gouttegd]

is the right way to:

Define a new type absolute_uri, which derives its specification from RFC 3986:

types:
  absolute_uri:
    uri: xsd:anyURI
    base: str
    pattern: '^([a-zA-Z][a-zA-Z0-9+.-]*):(?:\\/\\/)?[^\s]*$'

And the use that type like this:

slots:
  license:
    range: absolute_uri
    description: "An absolute URI identifying the license for this mapping set."

I wouldn’t bother with a pattern.

types:
  absolute_uri:
    uri: xsd:anyURI
    base: str
    description: An absolute URI as per RFC 3986.

with a note in the “backwards compatibility” section that SSSOM 1.1-compliant parsers MUST accept a relative URI when processing a SSSOM 1.0 set.

[nichtich]

Well, if https://w3id.org/linkml/specification is normative reference to define SSSOM then SSSOM implementers must also implement the LinkML specification or use an established, standard-compliant LinkML library to do so. I'll then not fully comply to SSSOM

[gouttegd]

SSSOM implementers must also implement the LinkML specification

The part of it that SSSOM depends on, yes. Which I agree is made quite difficult for non-Python developers because LinkML itself is poorly specified (as you noticed in the case of the uri type), which is one of the gripes I have with LinkML – in many cases, the LinkML-“defined” behaviour is “whatever Python does”.

use an established, standard-compliant LinkML library

There is no such thing except for Python – and in fact even the Python implementation of LinkML (the only implementation of LinkML) is not fully compliant either.

I'll then not fully comply to SSSOM

That’s your prerogative of course.

[gouttegd]

Pushed the issue upstream. We may not need to define our own absolute_uri type (as suggested above) if the LinkML folks can clarify once and for all that linkml:Uri is in fact intended to represent only absolute URIs.

[nichtich]

Thanks for investigation!