Open delenius opened 7 years ago
All entities of BFO have human readable labels. Which BFO do you look at? If you open BFO from: http://purl.obolibrary.org/obo/bfo.owl on protege. It displays human-readable names instead of BFO ids. Could you please check whether Protege has set 'render by label (rdfs:label')' on View menu?
Yes, I know there are rdfs:label
s on everything, and I can view by label. But it would be nice if the real names, i.e. the URIs, of the entities, were also human-readable.
The OBO Foundry URI principle proscribes this:
"Each class and relation (property) in the ontology must have a unique URI identifier. The URI should be constructed from a base URI, a prefix that is unique within the Foundry (e.g. GO, CHEBI, CL) and a local identifier (e.g. 0000001). The local identifier should not consist of labels or mnemonics meaningful to humans." http://obofoundry.org/principles/fp-003-uris.html
The rationale is given here: http://www.obofoundry.org/id-policy.html
The rationale is not convincing to me. Four points are made:
The URIs should resolve to useful information about a term. The URIs should be designed so that they can be maintained over time to keep pointing to useful information. Each OBO id is assigned to a only single term within the set of all OBO ontologies. There is a 1:1 mapping of OBO ids to Foundry-compliant URIs
This could all be accomplished while still using mnemonic human-readable names. You could introduce a new annotation property containing the OBO id.
Some downsides of the current scheme:
BFO0000001
, rather than entity
. The former are much easier to get wrong, and the code will be much less readable.
Has there been any discussion on generating human-readable names for the entities in the OWL version of BFO? While it is possible to view by rdfs:label in Protege, there are still many cases where it would be useful to have names like e.g. "bfo:continuant" insstead of "bfo:0000002" (e.g. when using other tools that are not so accommodating, or when browsing the raw OWL files).
Of course, I could add equivalent classes with more useful names, but that potentially generates more (unnecessary) reasoning steps.