Request for Feedback on Aligning PTRO Ontology with BFO

[Olga Ximena Giraldo]

Dear BFO community,

I am writing to seek your feedback regarding the PTRO ontology, which we have developed to support the representation of preclinical concepts in the domain of radiation oncology. Currently, PTRO reuses the UMLS Semantic Network (STY) as a lightweight upper-level structure, serving as a scaffold for concept organization.

As part of our ongoing efforts to gradually align PTRO with BFO-compliant ontologies, we have adopted the following annotation strategy for semantic mappings:

We use skos:exactMatch when a PTRO class based on STY is functionally equivalent to a concept in BFO or a BFO-aligned ontology (e.g., IAO).

We use skos:closeMatch when the concepts are closely related but not strictly equivalent.

Our goal is to enhance interoperability and semantic clarity while maintaining consistency with existing OBO Foundry practices.

We would greatly appreciate your insights on:

• The suitability of using skos:exactMatch and skos:closeMatch for this purpose.
• Best practices for transitioning from a STY-based structure to a more BFO-aligned model.
• Any known issues or recommendations related to such mapping strategies.

Thank you in advance for your time and guidance.

Best regards,

--

Olga Ximena Giraldo Pasmin

Orcid ID: orcid.org/0000-0003-2978-8922

[Pierre Grenon]

Dear Olga,

Thanks for posting about your efforts and PTRO which looks very exciting.

Apologies if this is not the feedback you seek yet it seems to me there is some level of ambiguity in the precise aim of the effort which makes it not completely straightforward to respond. I will explain my understanding hoping that some of it might help -- pick and mix... Others may have better suggestions based on their own experience and understanding.

Your aim could be one of the following:

1- terminology mapping between PTRO and BFO
2- terminology mapping between PTRO and OBO ontologies inspired by or aligned with BFO (some being too, ontologies).
3- ontological aligment of PTRO to BFO as an ontology.
4- ontological aligment of PTRO to a BFO inspired ontology.

The ambiguity between 1 and 3 is due to the fact that you are facing a fundamental issue that the underlying methodology used in developing PTRO follows design principles (radio ontology paper) that are at odds with the BFO underlying philosophy.

The ambiguity between 1 and 2 is due to the fact that PTRO is not the only one in the above situation and OBO includes also 'ontologies' that are terminologies in OWL. It is common too to reuse liberally identifiers, say from UMLS or NCIT, however, that doesn't solve the mismatch and sometimes creates serious misinterpretations.

The ambiguity between 3 and 4 is due to the fact that BFO is a high level ontology and aligning to it means falling under it whereas aligning to a domain ontology may very well be a matter of equivalence or articulable connection (if not duplication).

Terminologies

For 1 and 2, however, if you are attempting a terminology matching, using SKOS would suit (but then you are looking at BFO as a terminology, when it is not). If you still want to do that, you can resolve 1 vs 2 by erasing the distinction (as is actively done in the design principles of PTRO) and treating all ontologies as (kinda rich) terminologies. BFO alignment is not special in that respect and perhaps the OBO guidances will answer your needs: https://www.bioontology.org/wiki/BioPortal_Mappings

This being said, you will still need to understand BFO to make sure that your 'matches' are not problematic. It will be easier to map to OBO ontologies that have done part of this work. 

An example of a bad terminology match could happen with definable 'terms' such as Patient'. There is no such 'term' (class or otherwise) in BFO but BFO makes a distinction between a role -- such as being the patient in a procedure -- and the class of entities that have such a role. An ontology that follows BFO could have the 'PatientRole' specialisation of Role and would define Patient, say, using the PTRO notion of 'human patient', as the subclass of Person with a patient role (ignoring time, embedded into the role instance itself), as one option. It would be a mistake to map a 'patient role' to PTRO:Patient.

Ontologies

Now, regarding 3, (I will ignore 4 unless the example is domain specific), if that is of any interest. Mappings will not cut it. You have to consider reengineering PTRO, conceive it as an ontology and not simply a terminology derived hierarchy, in order to place it under BFO. This means also accepting design patterns in the construction and definition of terms -- such as with 'patient' or why you would distinguish 'patient' from 'subject', say.

PTRO is in fact a little bit hybrid so there is some common ground to some extent. It is using identifiers from what is fundamentally a terminology/semantic network but some of them are used more as a conventional knowledge representation ontology would -- for example, the hierarchy under Organism. So Organism fits well, even PhysicalObject -- as subclasses of MaterialEntity in BFO 2.0. In that respect the reuse of Person is also to PTRO's credit as it places it in that hierarchy instead of in that of ConceptualEntity. This being said, I do not understand the difference between Human and Person in this context, maybe that's just my shortcoming, in any case following BFO would require an explanation for such cases.

There is a likely natural ontological -- but not terminological -- alignment between PTRO:Event and BFO's processes. I'm not going to expand, aside from a top term in that branch, the rest will quickly become a domain ontology concern.

Problems lie with ConceptualEntity -- this is not BFO friendly, it is even sheitan -- IAO, that you cited, might help with a somewhat standard rework, but it can become very tedious. I may have missed some of the fine grained ideas in PTRO, however, it looks like there are serious design issues with this branch of the hierarchy, perhaps even independently of a BFO treatment. For example: 

1. PTRO:Domain may be a valid class, but as far as I understand them, the terms underneath ought to be instances (individuals) and not (sub)classes. That is, if the Body Weight Domain is _a_ domain and not a class of domains related to body weight. Because this bit deals with submissions, hence documents, I would approach it using IAO or OBI and define parts of documents and types thereof.

2. Most of the properties have (rdfs:)domain or range 'Subject Unique Identifier'. A subject unique identifier is properly represented as an identifier in PTRO. Yet an identifier has no weight and receives no treatment in the real world. All the properties are therefore misattributed. PTRO ought to represent subjects of procedures -- as individual organisms, human or mice. These ought to have the intended relationships. You can always derive more indirect relationships in terms of associations to or from an ID but it is not the fundamental ontological architecture of this domain. Again, organisms undergo procedures -- both are definable in a BFO style ontology, for which I would suggest OBI (other things exist) -- while the sort of properties identifiers have are such as 'being alphanumeric' or 'being 25 characters long' -- for which, OBI / IAO.

You may wish to do all or some of the following :
 
1- try matching PTRO and BFO as vocabularies -- not sure what benefit you derive aside from avoiding to use OBO ontologies that may have already done this work.
2- try matching to existing OBO ontologies, giving potentially richer mappings -- for which follow OBO's suggestions and reuse existing mappings
3- rework the ontological backbone of PTRO to make it fit under BFO _as an ontology. The mappings will be built in. Stress test the feasibility and complain when BFO comes short.
4- extend PTRO to make certain definitions explicitly articulated -- possibly, but not necessarily, using other OBO ontologies. The mappings will be either built in or achieved by equivalence, subclass or other more complex means. This may even induce richer terminological mappings, also capitalising on work done in the OBO community.

Hope this helps, I'm sure other people on this list will have more useful insights.

All the best,
Pierre

--
You received this message because you are subscribed to the Google Groups "BFO Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bfo-discuss...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bfo-discuss/CA%2BFAuA3jyKDW_mDUAG4qsJ9pCABVpOXvEneseDrZbZe-Lm333A%40mail.gmail.com.

[Olga Ximena Giraldo]

Dear Pierre,

Thank you very much for your detailed and insightful feedback—it is exactly the kind of expert perspective I was hoping to receive, and I truly appreciate the time you took to analyze the PTRO ontology in such depth.

You’ve made an important point about the ambiguity in PTRO’s current positioning between a terminology and an ontology, PTRO is indeed a hybrid—initially designed more as a pragmatic vocabulary rooted in semantic networks like STY/UMLS, and only partially adopting formal ontology patterns.

Your suggested options—especially (2), (3), and (4)—offer a valuable roadmap. We’ll start by leveraging existing OBO mappings and then incrementally rework PTRO’s backbone using community-adopted patterns, testing feasibility as we go.

Thanks again for such a constructive and thoughtful response. We’d be glad to share updates as we progress and welcome any further input from you and others on this list.

All the best,
Olga

To view this discussion visit https://groups.google.com/d/msgid/bfo-discuss/CAAkf34xrN5F_t1r1%3DxcAutyXvkMvOOJ6U6cXBwGy53ozh8Ascg%40mail.gmail.com.

--

Olga Ximena Giraldo Pasmin

Orcid ID: orcid.org/0000-0003-2978-8922

Twiter: @olgaxgiraldo

Skype:olgaximenagiraldo

Website: http://oxgiraldo.wordpress.com