Proposal: Normalized BFO #221
Comments
|
Could adding synonyms annotation properties to BFO classes with the values BFON(BFOClass) be an easy first step to see how the community responds? I like the idea in the post above, I'm wondering if we should work a little bit more on the details (e.g. defining the has-characteristic OP, defining the suitable range etc). Adding alternative terms would allow us time to formalise this better while gauging interest? |
|
On 25 Oct 2018, at 5:02, Melanie Courtot wrote:
Could adding synonyms annotation properties to BFO classes with the
values BFON(BFOClass) be an easy first step to see how the community
responds?
Reusing the example above, this would mean bfo:continuant would have
an alternative term property with value 'exists in whole at a moment
in time'.
formally this is the name of the property of a continuant, not the
continuant itself. But we could certainly release a proposed set of
names if it helps. I don't think we need or want to introduce any
changes to BFO names or synonyms though.
I like the idea in the post above, I'm wondering if we should work a
little bit more on the details (e.g. defining the has-characteristic
OP, defining the suitable range etc). Adding alternative terms would
allow us time to formalise this better while gauging interest?
This property would be taken as a primitive, the range wouldn't
necessarily be in the domain of BFO, since they are properties that
define BFO classes (although some may be in the domain of BFO, e.g
material entity EquivalentTo bearer_of some mass).
A semantically identical proposal with the similar structural properties
would be to create a data property for each BFO class, e.g. continuant
EquivalentClass is_continuant xsd:true. This may be seen as preferable
as it doesn't introduce any new non-BFO individuals into the model.
|
|
+1 to releasing list of proposed names, saying those will be used to logically define BFO classes. As there have been many request for clearer names in the past this should be well received, and we can then proceed with implementation as you propose. I agree we don't want to alter the label of the existing classes. I'm not keen on the data propertyproposal because I don't see how saying |
I really don't think it matters much. The names can all be
The axiom is not there to clarify things for humans. On the contrary, that humans would not see the BFO class is the point of the proposal. They would instead see ugly axioms such as |
This versions sounds promising to me - pure semantic sugar that doesn't require any arguments over ontological status. Could you outline a workflow for working with it?? At some point you still need to import BFO to infer classification and test consistency, but presumably that would be handled outside of standard imports? |
|
I like the use of data properties in this way too. I was worried reading the original approach how something like "BFON(material entity) rdfs:label 'has non-zero mass'" would interrelate with the PATO mass quality. |
|
I think having a BFO for non-philosophers would be nice. Altering the names and descriptions can only go so far. The abstractions are the same and will have the same overhead. Having more tractable labels and descriptions may offer a great deal of value to end users. Is there a sample population that this approach could be validated with? What might a pilot test of this approach be? a set of examples with users followed by a few questions that address acceptability and appropriateness? |
Just to reiterate, my proposal is not to rename. It is to create a shadow hierarchy that could be used with the same logical entailments. It would have a vastly lower cognitive overhead for domain ontologies, as it would no longer be necessary for domain scientists to drill down multiple levels to get the root terms they understand. |
One use case for this is to expressionize BFO; see BFO-ontology/BFO#221 for context
and others
BFO has many advantages, providing a standard for aligning upper
levels across different ontologies, but current usage suffers some issues:
The labels in BFO are largely invented by philosophers and are not
part of normal scientific vernacular.
This is compounded by the fact that assertion of subClassOf to BFO
classes forces the BFO hierarchy to be prominent in a generic ontology
display. While in theory it is possible to hide this, overall
resources are limited, and we have yet to see this happen in any
single generic ontology browser, never mind ubiquitously.
The standard methodology for usage of BFO is to directly assert a
subClassOf axiom to a BFO class.
A more modern ontology development strategy is to assert
characteristics and to infer the subClassOf axiom.
A side-effect of this is asserted polyhierarchies. For example,
asserting that a material anatomical entity is material entity and an
anatomical entity.
Some ontologies overcommit to very specific classes without knowing
semantics. It would be better for domain ontologies to focus on
stating the characteristics of entities in their domain and for
classification to the most specific BFO class to be inferred.
It is difficult to mix and match different UOs without asserting
confusing polyhierarchies (see above).
Proposal
Create a parallel/shadow hierarchy to BFO, representing
characteristics that can be attributed to entities. For example,
rather than a class 'continuant', we would have a characteristic of
'existing in whole at a moment of time'.
Use an object property has-characteristic to connect entities in
our domain to these characteristics. E.g. instead of asserting
SubClassOf continuant, assertSubClassOf has-characteristic some 'existing in whole at a moment in time'.We defer on the ontological nature of these characteristics for now,
but note that some can be represented using ontologies like PATO,
e.g. 'bearer of some mass' is the defining characteristic/quality of a
material entity (in fact CARO already uses this to avoid asserting MI).
The general design pattern is:
BFOClass EquivalentTo has-characteristic some BFON(BFOClass)
The BFON class can optionally be renamed. E.g.:
Logical axioms can be rewritten in terms of BFON, e.g.
Domain ontologies do not need to commit directly to BFO classes
(although they can). They instead commit to characteristics as
required. If BFO is imported, we get classification to the most
specific classes. If BFO is not important, and we instead import BFON
(plus rewritten axioms), we get the same entailment benefits.
The OWL is logically/semantically equivalent, so it could be argued
this is a pointless exercise in deckchair shuffling. However, when it
comes to human usability there is more to an ontology that logical
axioms. Ontology structure and ontology terminology are impactful.
The BFON structure and lexicon has advantages for both human consumers
and producers of ontologies:
The ontology top level can be domain entities that are generally
understood by domain scientists. For example, a top level with classes
such as "social entity", "biological entity", "chemical entity", with
sub-levels for organism, gross anatomical structure, biological
process, investigation, etc.
BFO will still be "there" in the form of BFON classes, but these would
structurally and visually form a side-hierarchy rather than being prominent.
Ontology developers can focus on asserting characteristics (e.g. as
existential axioms) rather than direct is-a assertion of a BFO
category. This is more in line with modern ontology development
following Rector normalization, avoids assertion of MI.
The text was updated successfully, but these errors were encountered: