-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update namespace #42
Update namespace #42
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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.ttl
file to be a pre-cursor for a "one-stop-shop"-CIF ontology. I.e., one that imports allcif_*.ttl
files, 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_*.ttl
files concerningcif_top.ttl
.So instead we now just have
cif_top.ttl
andcif_core.ttl
.I've also removed the
crystallography.ttl
file, but will recreate it in the emmo-repo/domain-crystallography repository.Question: Was the point of
dic2owl
/generate_cif.py
that we don't actually createcif_core.ttl
, but rather generate it (and others) on-the-fly for thegh-pages
branch?I noted that there also is a big difference in syntax between the generated OWL Turtle file using
dic2owl
/generate_cif.py
and 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?