Deconflicting IBEs and ICEs

[neilotte]

Only ICEs can cco:represents, but a few definitions in CCO imply IBEs can represent. I recommend their definitions are adjusted to clarify that this is not the case:

• cco:List is defined as 'An Information Bearing Artifact that represents an ordered sequence of values, where the same value may occur more than once.'

• cco:CodeList is defined as 'A List that represents an ordered sequence of Information Bearing Entities that bear Code Identifiers.'

• cco:Chart is defined as 'An Image that is designed to represent an Information Content Entity by means of Written Symbols in order to convey that information in a readily understandable format.'

[jonathanvajda]

Aren't the first two properly subclasses of ICE, not IBE? If so, then if someone still wants to talk about the bearers, then just talk about them as subclasses of cco:Document or perhaps defined class with an axiom such as cco:Document bearer_of cco:List

For cco:Chart rather than say 'represents', should it say

• is 'bearer of' (bfo:0000020) some cco:InformationQualityentity that 'concretizes' an ICE by means of Written Symbols in order to convey that information in a readily understandable format

?

[mark-jensen]

@neilotte and @jonathanvajda We are currently in the process of reviewing several of the subclasses of ‘Information Bearing Artifact’, considering how to refactor where appropriate. If these classes end up with specific IBA counterparts, the defs will certainly be redone to properly reflect that they carry the thing that represents. Thanks!

[jonathanvajda]

This topic is of renewed interest on both fronts @mark-jensen. A partner of mine just found this same issue that Neil raised. I am also working with ontology working group where this IBE-ICE issue has been under discussion.

[neilotte]

@johnbeve May I ask you to look at this PR thread when you have a moment?

#319

[johnbeve]

@neilotte Comments in the #319 PR sir

[neilotte]

This issue was addressed in #319 . Closing now.