Add check for malformed IRI in IOHelper.createIRI

[beckyjackson]

Resolves #880

• docs/ have been added/updated
• tests have been added/updated
• mvn verify says all tests pass
• mvn site says all JavaDocs correct
• CHANGELOG.md has been updated

This is a bit more sane than trying to do a regex match for a valid URL. If the output IRI is just a CURIE, this will fail (e.g., undefined prefix when running template). If the output IRI has a space it it, this will also fail (which we were just checking for a space before).

[matentzn]

This is what I suggest as well - just consider the rare cases where this will fail:

1. ontology IRIs which are by default when saved with Protege urns
2. Its strictly speaking allowed to use URNs instead of URLs for IRIs as IRIs are extensions of URIs, but I think this is sane for 99.95% of all cases.

[beckyjackson]

This won’t impact ROBOT loading ontologies that have the Protege URN, since it’s only for creating new IRIs. I don’t think that would ever be used as a new IRI in a template, but perhaps this is too strict?

…

On Mon, Jun 21, 2021 at 1:33 AM Nico Matentzoglu ***@***.***> wrote: This is what I suggest as well - just consider the rare cases where this will fail: 1. ontology IRIs which are by default when saved with Protege urns 2. Its strictly speaking allowed to use URNs instead of URLs for IRIs as IRIs are extensions of URIs, but I think this is sane for 99.95% of all cases. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#882 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD7ZMRXB2VXD7WYFW3BXC7DTT32MPANCNFSM466KMJFQ> .

[beckyjackson]

We could also add to the method - if the IRI starts with urn: and doesn't have a space in it, it should be assumed valid. We could implement a check for URNs but I haven't seen them used in the wild, so I don't know if it's worth it (https://stackoverflow.com/a/5492927). I did check this regex against a bunch of URNs and it seems to work as expected (e.g. works for urn:isbn:0451450523 but fails for urn:123456)

[matentzn]

I would kinda tend towards adding URN checking support, but defer to your better judgement. A question that I never quite answered to myself: what is the advantage of using try: new URL(...) compared to using a regular expression for matching URLs?

[beckyjackson]

Here's another option: we could use the URLValidator from commons-validator, but that requires adding an additional dependency. This validator is more strict than new URL(...), though, as just passing http:// to that would pass - which would not be a valid IRI. new URL(...) will catch most issues, though. Maybe this is important enough to add another dependency, though.

I have concerns about just using regex to match a URL because there are so many variations on what a "good" regex pattern for a URL is. I just prefer to use existing and tested tools.

[matentzn]

ok totally fine with new URL(...)!