Rename ontology uri property to iri - #400
jochenchrist wants to merge 2 commits into
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)
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.
5 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.