CommonCoreOntologies
CommonCoreOntologies copied to clipboard
What happened to bearer-of subproperties?
The version of BFO on the master branch, which @mark-jensen committed on 2021-03-01, has five subproperties of "bearer of" (RO_0000053). The version of BFO on the bfo2020 branch, committed on 2021-4-23, has only one subproperty of the equivalently labeled property (BFO_0000196). Are there plans to add equivalents to the others (has role, has disposition, etc.)? Or were they deliberately removed?
@swartik The change to using BFO2020 properties required dropping the overlapping RO ones. All of those subproperties were from RO, so we deliberately deleted them. There are no plans currently to add equivalents to the BFO2020 version of CCO.
Are you using this version of CCO that imports BFO2020? If so, can you comment on how that's worked for you so far? Specifically I am curious what kind of troubles you have encountered using the new temporalized properties, as well as with updating or integrating data that uses the old ones from RO/ERO.
@mark-jensen Thanks for the information. Yes, we are using the version of CCO that imports BFO2020. We anticipate using some of the classes in DICO, which also uses that CCO/BFO combination. Even if we didn't plan to use DICO, temporalized relationships are important to us, so I would have argued for using them.
We aren't far enough along to have encountered troubles. Expect me to post more messages.
@swartik One of the issues with the temporalized relations in BFO2020 is that it does not support the representation of nonrigid classes using equivalence axioms.
What does everybody think about OWLStar? https://github.com/cmungall/owlstar
@mark-jensen and others have asked for my reaction to the propetry structure in BFO 2020. I didn't respond earlier because I was only building models, not populating them. Now that I have some experience populating models (even if they're toys built for explanatory purposes), I'd like to share a few thoughts.
I'm beginning to wonder how useful the "*-at-some-time" properties are in practice. Let me illustrate using BFO_0000178/BFO_0000176 (has continuant part at some time/continuant part of at some time). Suppose I need to model:
a obo:BFO_0000176 b .
Many of the queries I write against my knowledge bases have a temporal component. If a knowledge base asserts that a parthood relationship applies at some time, I want to know whether it applies at some specific time. I end up modeling parthood using:
:a obo:BFO_0000176 :b . # continuant part of at some time
:a obo:BFO_0000196 :part-role . # bearer of
:parthood-stasis obo:BFO_0000167 # has participant at all times
:b , :a , :part-role .
:parthood-stasis obo:BFO_0000199 :temporal-region . # occupies temporal region
(I wanted to use an image, but github won't let me upload it. Sorry.)
My KBs don't necessarily have starting and ending instants, and their presence or absence is important to me. But that's another matter. My point is that the SPARQL queries I write focus on every part of this pattern except the continuant part of at some time
triple. One advantage of using continuant part of at some time
would be to take advantage of SPARQL's one-or-more-path syntax:
?a obo:BFO_0000176+ ?topEntity .
I find I can't do that because I'm only interested in property paths where the temporal regions of parthood match. At-all-times is transitive. At-some-time might or might not be.
This leads me to wonder what value the "*-at-some-time" properties add. At best they are a shorthand, simplifying SPARQL queries in situations where I happen to know that parthood is truly transitive. At worst they are misleading.
I think my recommendation at this time is to document the expected usage patterns. Specifically, the CCO documentation should state that every use of a "*-at-some-time" property should also include a specifically dependent continuant, a stasis, and a temporal region, associated as above.
Of course, my experiences reflect the kinds of data I'm expressing. I'd like to know whether or not others have had similar experiences.