NTR: is about

[wdduncan]

Not really a new term request (I suppose). But #535 made me realize that is about is not included as part of RO. Should we be importing it from IAO? May be useful for other "about" relations that may be needed.

[matentzn]

I would really like to know the value of this relationship - what is the range and the domain? I find it very confusing how often I see these in OBO.

[wdduncan]

The domain of is about is information content entity. The is about relation is also in COB.

It is useful in cases where it is important to distinguish information from what the information represents. E.g., A diagnosis "is about" a patient's malady. It is not the same thing as the malady itself.

Do you have an example of case that confuses you?

[matentzn]

For me is about sounds like its in the same bin of relations is related to.. It just sound too vague to be useful.. But maybe I am wrong, and anyways, that ship has sailed.

[wdduncan]

Not sure what you mean by being vague. It is used to relate information to other things. The domain is very specific.

[wdduncan]

There are also a number of more specific sub-relations of is about:

• mentions
• denotes
• is quality measurement of
• etc.

It is best to use one of the sub-relations.

[matentzn]

Maybe.. just irks me probably because of EFO where is about is used to relate everything to everything else.

[ddooley]

"Is about" is in my view a shortcut relation that simply hides intermediary process modelling between information and all the inputs to processes that it results from (observations, calculations). (It is sort of transitively about anything that its ancestral process chain has as inputs). It does the same thing as "derives from" in the physical world between material entities.

I use it when general relations suffice and don't leave ambiguity. If there's ambiguity then we get into naming sub-properties like "is quality measurement of" :

But does one actually need to say "is quality measurement of", or does it suffice to write a query in which one is looking for datums that "is about" some quality/characteristic? Why choose more particular language when general language can be used with domain and range constraints in querying to the same purpose?

[dosumis]

There are also a number of more specific sub-relations of is about:

• mentions
• denotes

I think these should also die. Isn't the point of ontology classes that they all denote something? 'mentions' I guess could be used to relate a piece of text to a word within it, but I suspect it will just encourage use-mention confusion.

[wdduncan]

@ddooley I agree with your sentiment of is about of being a kind of shortcut that hides a number of information processings that are going on. After all, the notion of a GDC is kind of weird (i.e., an individual that can exist in multiple places at the same time).

But does one actually need to say "is quality measurement of", or does it suffice to write a query in which one is looking for datums that "is about" some quality/characteristic?

Yes, you can. I thought the reason for creating is quality measurement of was for it to be a shortcut. Right?

@dosumis I don't follow your reasoning for getting rid of denotes. Sure, every class denotes/represents something. The same can be said about whole host of information systems, not just ontologies. However, representing that a piece of information denotes something is a different issue.

[ddooley]

@wdduncan I'd say "quality measurement of" is a minor shortcut insofar is it eliminates need in query for adding range = [edit] quality/characteristic". But its not a shortcut of intermediary entities beyond what its parent "is about" accomplishes.

I'd been using [identifier class, like ISBN, DOI etc.] "denotes" some entity. But same argument as above applies, "is about" can suffice if simply adding constraint on domain that it be an identifier class.

I was exploring use of "mentions" to attach between textual documents and data models that might not fully describe the textual stuff. It seems handy for protocols and recipes that aren't fully process modelled but one has at least knowledge of processes or ingredients to convey. More on this divide between brief textual representation and intricate model coming up in a recipe model paper that picks apart ingredient lists, instructions etc!

[wdduncan]

I'd say "quality measurement of" is a minor shortcut insofar is it eliminates need in query for adding range = measurement datum". But its not a shortcut of intermediary entities beyond what its parent "is about" accomplishes.

Yes, I would agree with that :)
(Note, the word 'that' denotes/refers to the above quoted statement, but does not mention it.)

More on this divide between brief textual representation and intricate model coming up in a recipe model paper that picks apart ingredient lists, instructions etc!

At ICBO 2018, I had an abstract about something along these lines for pathology reports. See here if interested.

[cmungall]

I think we can close this issue

• if people want to use is-about they can use the existing IAO ID (personally I would always assert a more precise relation, and I find this relation useless for querying it has been used so inconsistently)
• a proposal is obsolete the IAO ID and replace it with an RO ID will face resistance
• having RO adopt IAO adds complexity and gains nothing

[wdduncan]

The reason for adding is about is to provide the structure needed to create property chains that use ICEs. See #535. This issue is now closed, but the need for is about may arise in the future.

I don't think we would need to change the IRI or take over governance of is about. We can use rdfs:isDefinedBy obo:IAO to make it clear that the term is controlled by IAO.

In any case, since #535 has been closed, there is not a pressing need for is about. I am okay with closing the issue, but we may want to consider whether it is advantageous to do a little bit of future proofing.

[wdduncan]

If we add to RO, the OBI group should make decisions about how the design patterns / clarifications for is about.

Consensus: We should add it using an RO id. We will delay final decision until next meeting to give others a chance to comment.