Parser.py doesn't use prefix when importing

[Evan M. R. Sampson]

I may be incorrect about this, but Parser.py doesn't seem able to use the prefix setting from the conf file. It seems that almost all cl-imports in COLORE start with "http://colore.oor.net". Right now, Parser.py tries to read these URLs as paths.

[Evan M. R. Sampson]

@Fxhnd additionally Parser.py lines 95-97 don't make much sense to me:
sub, base = self.basepath
subbed_path = path.replace(self.basepath[0], self.basepath[1])
new_ontology = Parser.parse_file(subbed_path, sub, base, resolve)
Particularly the second line here. Basepath[0] seems to be the same thing as sub, and Basepath[1] seems to be the same thing as base. Why do we need to replace instances of sub in the path with the base? I feel like that will usually give you an invalid path.

[Robert Powell]

I'll admit I had to stare at it longer than I should've to figure out what I was doing.

Your first comment is correct, there is nothing in Parser.py that ties it to the config files in any way. Instead you'll see that the Parser.py has a function parse_file which accepts a path to a file, a substitutable string, and a base path. If you run Parser.py on the command line you'll see these are accepted as optional parameters on the command line if you provide the --resolve flag.

Given the resolve flag and the additional --sub and --base parameters it'll force that function to substitute every "sub" string (in this case the http://colore.oor.net) with the "base" string (the local basepath to the ontology folder) that it finds in any import statements. So it does work as intended so long as those sub and base parameters are provided, if they're not the parser doesn't attempt to resolve any import statements at all.

This is where a little chicken and egg problem comes in. The parse_file function yields an Ontology which has a list of all of it's imports. Now, if we wanted to fully resolve all those imports we need some way to inspect those imports within the Ontology() class so that we can call the parse_file again to recursively yield more Ontology() objects. I went the quick and dirty route by giving the resolve_imports() method of the Ontology() the ability to call parse_file. The problem was that the Ontology() would then need to know the basepath/sub-string pair to be able to correctly resolve the imports. This is where the poorly named instance variables, self.basepath, comes into play. It's a tuple of (sub,base) that the Ontology holds onto to pass back to the parse_file function.

So what that for loop is effectively doing is looking through all the imports (which still have the http://blah/filename.cliff) and fixing them so they actually point to a file on the local file system. After they've been fixed the new path is given to the parse_file() to create a new Ontology() object.

sub, base = self.basepath
subbed_path = path.replace(self.basepath[0], self.basepath[1])
new_ontology = Parser.parse_file(subbed_path, sub, base, resolve)

should really be renamed to

http_prefix, base_folder = self.basepath
local_path = path.replace(http_prefix, base_folder)
imported_ontology = Parser.parse_file(local_path, http_prefix, base_folder, resolve)