Update namespace #42
Update namespace #42
Conversation
There was a problem hiding this comment.
Sorry for this late review. Just two questions
- is there a good reason to remove the example?
- do we really want to keep the generated cif_core.ttl in the repo? It has the potential to introduce a lot of diffs for even small changes in the source, making the repo large and slow to work with
ontology/catalog-v001.xml
Outdated
| <uri name="http://emmo.info/domain-crystallography/cif_top" uri="cif_top.ttl"/> | ||
| <uri name="http://emmo.info/domain-crystallography/0.0.1/cif_top" uri="cif_top.ttl"/> | ||
| <uri name="http://emmo.info/domain-crystallography/0.0.1/cif_core" uri="cif_core.ttl"/> | ||
| <uri name="http://emmo.info/domain-crystallography/0.0.1/cif_example" uri="cif_example.ttl"/> |
There was a problem hiding this comment.
Isn't the example nice to keep?
No. Nothing other than cleaning up.
This point is what I referred to in the original post as well. I am unsure. If we can work with generating it locally for everyone, then that should be fine? |
I would vote for keeping both example and the generated file. The main information in this repo is the *.ttl file, the scripts generating it are auxiliary. Also, I have some problems running Python code (compatibility, library dependencies), and there is always a question whether the *.ttl file generated on different machines is the same (different Python version/libraries might be incompatible).
This is indeed a nuisance, although Subversion handles such situations just fine, and I would be surprised if Git does not. |
Change namespace from domain-crystallography to CIF-ontology. Update `cif.ttl` to be a "one-stop-shop" ontology for all things CIF. This means it imports all `cif_*.ttl` files, except `cif_top.ttl`, which is imported indirectly through the others.
The reason is that the version of the CIF top ontology cannot be uniquely defined for all subsequent imports of CIF_*.ttl files. Say, for example, `cif_core.dic` uses v1.0.0 of `cif_top.ttl` and `cif_sym.ttl` uses v0.9.5 of `cif_top.ttl` (or similar), the `cif.ttl` file cannot handle this and import both ontologies. Or rather, there is a high possibility that these two versions cannot be accommodated at the same time.
CasperWA
force-pushed
the
ontology-file-hierarchy
branch
from
4cd320b
to
451d41b
Compare
|
The major changes introduced in #50 have rendered the majority of this PR redundant. |
Through some iterations here, I have updated the ontology files in the
ontology/folder.I started out by updating the
cif.ttlfile to be a pre-cursor for a "one-stop-shop"-CIF ontology. I.e., one that imports allcif_*.ttlfiles, excludingcif_top.ttl, since this will be imported implicitly.However, I've come to the conclusion that this is not feasible due to potential version differences in the
cif_*.ttlfiles concerningcif_top.ttl.So instead we now just have
cif_top.ttlandcif_core.ttl.I've also removed the
crystallography.ttlfile, but will recreate it in the emmo-repo/domain-crystallography repository.Question: Was the point of
dic2owl/generate_cif.pythat we don't actually createcif_core.ttl, but rather generate it (and others) on-the-fly for thegh-pagesbranch?I noted that there also is a big difference in syntax between the generated OWL Turtle file using
dic2owl/generate_cif.pyand if one loads the generated.ttl-file and re-saves it as a Turtle file. Is the syntax not actually Turtle for the generated ontology file?