Rename ontology uri property to iri - #400
Conversation
Follow-up to apache#332. The global identifier on concepts and relationships is now called iri instead of uri, as agreed in the PR discussion (IRI per RFC 3987 covers both full IRIs and QNames). The prefixes map uses the JSON Schema iri format accordingly.
Adds the prefixes field to the top-level table, the iri field to the concept and relationship tables, and a Global identifiers section that explains IRIs, QName expansion against prefixes, and how IRIs relate to local names.
| The `iri` field accepts two forms: | ||
|
|
||
| - A full IRI, e.g. `http://xmlns.com/foaf/0.1/Agent`. | ||
| - A QName of the form `prefix:local`, e.g. `foaf:Agent`, where `prefix` is declared in the |
There was a problem hiding this comment.
Not directly related to this PR, but... Please note that deciding which form to parse here is not really possible to do for all possible cases. For example urn:isbn:whatever is a valid IRI. What if you have a prefix urn:?
In LinkML there is the exact same issue with the uriorcurie datatype. See: linkml/linkml#3906
Should there be a follow-up to define a clear algorithm for how iri should be parsed and serialized?
There was a problem hiding this comment.
URNs are valid IRIs (from RDC 3987) so they should be allowed. @jochenchrist perhaps the md can reflect this:
The ‘irk’ field accepts two forms:
- A full IRI, e.g.
http://xmlns.com/foaf/0.1/Agent,urn:foaf:Agent - A QName …
I’m also curious about @Ostrzyciel’s statements that it’s not possible to implement all cases. RDF processors have been doing this for years. Do I misunderstand your statement?
There was a problem hiding this comment.
Good point. I think @Ostrzyciel is pointing that how can we decide if a value is a QName (to lookup the prefix) vs. an URN, as both have the form schema:values.
However, URNs always start with urn:....
An idea might be to not allow a prefix urn.
I will update the PR accordingly to mention that URNs are alos allowed as IRI.
There was a problem hiding this comment.
I’m also curious about @Ostrzyciel’s statements that it’s not possible to implement all cases. RDF processors have been doing this for years. Do I misunderstand your statement?
In Turtle, these two have different syntaxes. Full IRIs are: <urn:fullIri>. And CURIES/QNames are: urn:qname. They are interpreted differently.
An idea might be to not allow a prefix urn.
URNs are just one possible case where this will break :) IRIs have a ton of forms. You can get a sample here: https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#Example_URIs
As for the solution to this conundrum: I would recommend a solution along the lines of this one proposed in LinkML: linkml/linkml#3906 (comment)
There was a problem hiding this comment.
So, what do we do about this ambiguity?
I'm fine to merge as is and follow up but it's something we should address.
Concretely, my take on that: if prefixes declares urn: http://example.org/ns# and a concept sets iri: urn:isbn:0451450523 (a valid RFC 3987 IRI), does that get expanded as a QName into http://example.org/ns#isbn:0451450523 or preserved as the literal URN?
As written, an implementer following "a QName ... where prefix is declared in the ontology-level prefixes map" would expend it (silently producing the wrong global identifier).
Where should we move here? @jochenchrist ?
kayemkim
left a comment
kayemkim
left a comment
There was a problem hiding this comment.
One data point for the QName versus full IRI thread: nothing in the repo enforces either form today. validation/validate.py builds Draft202012Validator(schema) without a format checker, so format: iri (like format: uri before it) is descriptive only, and jsonschema ships no iri checker anyway unless rfc3987 is installed. The same goes for the "a QName whose prefix is not declared in prefixes is invalid" sentence; the validator accepts any string. So whichever resolution rule comes out of that discussion, it would need a semantic check next to the reference and arity ones, not a schema keyword. Not a blocker for this rename. Checked on current main that no example, fixture or converter in the repo uses the uri field, so the rename is complete as is.
|
|
||
| Here `Agent` and `Agent.has_homepage` are identified by QNames that resolve against the `foaf` | ||
| prefix, while `Organization` is identified by a full IRI. Both forms denote the same kind of | ||
| identifier; the QName is merely shorthand. A QName whose prefix is not declared in `prefixes` |
There was a problem hiding this comment.
Nit: this states a validity rule, but nothing enforce it: ontology/ontology.json schema types iri as a plain string with no pattern tying it to the declared prefixes key, and validation/validate.py builds its Draft202012Validator with no custom format/keyword to check this cross-field constraint. Right now iri: bogus:Thing with no bogus prefix declared passes validation despite being "invalid" per this spec.
It has been mentioned before by @kayemkim . I believe either the schema/validator should enforce this, or the doc should say explicitly that this is a semantic constraint left to tooling outside validate.py, so implementers don't assume schema validation covers it.
…properties Resolve conflicts with the uri -> iri rename (apache#400) by keeping both the custom_properties additions and the iri/prefixes docs. Update the FOAF example to use iri and add the ASF license header required by the new license check.
6 participants
Follow-up to #332.
Renames the optional global identifier on concepts and relationships from
uritoiri, as agreed in the discussion on #332 (IRI per RFC 3987). Theprefixesmap now uses the JSON Schemairiformat, and the descriptions say IRI instead of URI.Also documents the new fields in
ontology.md:prefixesin the top-level table,iriin the concept and relationship tables, and a new "Global identifiers" section that explains IRIs, QName expansion againstprefixes, and that IRIs do not change how local names are used in expressions and mappings. The example in that section validates against the updated schema.