Some of the ontology files contain URIs that end with hash signs. For example, in commit 52e6b1f8 (head of develop branch at the time of writing), lines 14 and 15 of src/ontology/mappings/d3fend-cco.ttl are:
Protégé version 5.6.3 won't load this. It reports:
An error occurred whilst loading the ontology at file:/home/swartik/d3fend-ontology/src/ontology/mappings/d3fend-cco.ttl. Cause: URI has a fragment component
Removing the trailing # from the imported ontology on line 15 fixes the problem.
Is there a reason why the URIs end with hash signs? This is common in prefix declarations but not in URIs, at least in my experience.
I see that, in dist/public/d3fend-cco.owl, the ontology's URI ends with a hash sign. Protege loads it without complaint. Apparently the hash sign only interferes with import directives. But I'd still like to know why hash signs are used.
Some of the ontology files contain URIs that end with hash signs. For example, in commit 52e6b1f8 (head of develop branch at the time of writing), lines 14 and 15 of src/ontology/mappings/d3fend-cco.ttl are:
Protégé version 5.6.3 won't load this. It reports:
Removing the trailing # from the imported ontology on line 15 fixes the problem.
Is there a reason why the URIs end with hash signs? This is common in prefix declarations but not in URIs, at least in my experience.
I see that, in dist/public/d3fend-cco.owl, the ontology's URI ends with a hash sign. Protege loads it without complaint. Apparently the hash sign only interferes with import directives. But I'd still like to know why hash signs are used.