-
Notifications
You must be signed in to change notification settings - Fork 3
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
Separate out darwin core into imports #95
Comments
Good point, @cmungall. We do in fact import a separate file for Darwin Core classes, but merge them during the release. That same file includes all of the Darwin Core properties, which we use all the time with BCO applications, so I want to keep those. Do you suggest that we keep the import file as part of the BCO release process but don't merge it, or maintain a separate file in our repo that people can import if they want? That separate file would include the mappings (equivalency axioms) then, instead of the main BCO file. Can you please point me to one of the mapping files distributed e.g., with UBERON so I can see how you do it? |
I'm not familiar enough with all use cases to definitively advise, but one thing that would be useful would be to include a bco-base.owl module that is just bco entities and axioms about those entities You can see the bridge ontologies for uberon here: http://uberon.github.io/downloads.html#bridge |
@cmungall My intent is to make separate OWL files for DwC, one with all DwC classes and dwc:terms (as data properties) and another with all dwciri terms (which are object properties), plus a bridging files to specify the axioms relating dwc terms to BCO terms (e.g., equivalency between BCO classes and dwc classes). The files could then live in the Since the term sources are not in OBO library, I am not sure if I can use the make file to build the imports, but I will at least try to script it. Is there an option to set use the makefile to import from some other endpoint? I'm fairly confident that I can figure out how to get the make file to import these ontologies once they are made, and to create versions of BCO with and without them. Does this plan sound reasonable? Any advice on improvements? |
Part of this process needs to be deciding whether to import DwC object properties. We are currently only importing data properties. |
If I want to import bco, is the intent that I use dwc classes as if they were other obo classes?
Or is the intent to provide a mapping, similar to the equivalence axioms distributed alongside mondo, uberon to non obo-resources?
Would it make sense to separate dwc into a separate import, so that people using bco wouldn't accidentally end up using dwc classes?
The text was updated successfully, but these errors were encountered: