#564 and #620 - ICE-IBA Refactor #674
Conversation
a. For IBA and IBE, add the alternate labels ‘Information Carrying Artifact’ and ‘Information Carrying Entity’, respectively, and add the comment to IBE: ‘This class continues to use the work ‘bearing’ in its rdfs:label because of potential confusion with the acronym ‘ICE’, which is widely used for information content entity.’ b. Add a similar comment for IBA that indicates by “bears” we mean that the IBA ‘is carrier of’ an ICE. c. IBA should get the comment: “This class continues to use the word ‘bearing’ in its rdfs:label for legacy reasons. It is understood that an IBA bears the concretization of an ICE and not the ICE directly.” d. Update all rdfs:labels of subclasses of IBA to use prefix ‘Material Copy of’ and make their existing rdfs:label an alternative label. For instance, the class ‘Book’ will have the rdfs:label ‘Material Copy of a Book’ and the alternative label ‘Book. e. Create a subclass of ‘Information Content Entity’ called ‘Media Content Entity’ with the definition ‘An information content entity presented in a canonical media format’. f. Ensure the entire IBA subclass directory is then copied under ‘Media Content Entity’ such that, for example, the class ‘Book’ is now an ICE. g. Add a subclass axiom on to each IBA classes which declares each ‘is carrier of’ some <corresponding media content entity>. For instance, every ‘Physical Copy of a Book’ is a carrier of some Book’. h. In both the IBA and the ICE hierarchy, ensure that Book, Journal Article, and Spreadsheet (in both senses) are under ‘Document’ (again, in both senses). i. Update the rdfs:label of ‘Document’ to ‘Document Content Entity’ j. Rename ‘Document Form’ to ‘Form Document’ k. Place ‘Document Field Content’ under ICE and add that is a continuant part of some Document. Add the alternative label ‘Document Field’. l. Move ‘Document Field’ from under IBE and place under IBA. m. Review all definitions of every class affected here to ensure the definitions clearly describe either ICEs or IBAs (e.g. a relationship like ‘is carrier of’ or ‘represents’ is not used inappropriately within one of these definitions).
There was a problem hiding this comment.
There is some issue with whitespace being added in the Artifact Ontology causing diffs to render badly. Essentially, an extra space is added for some of the lines within a declaration block. Using a diff tool where whitespace and line endings are ignored makes the review process easier. I use P4Merge.
However, the Information Entity Ontology is a mess and needs to fixed before a proper review can be made. Lots of stubbed out declarations, etc. @neilotte Will you please address all the extra noise in that file
mark-jensen
left a comment
mark-jensen
left a comment
There was a problem hiding this comment.
The definitions in the IBA hierarchy are not using the updated labels for their parents.
E.g., Def for 'Material Copy of a One-Dimensional Barcode':
"A Barcode that is designed to bear parallel lines of varying widths and spacing that concretize some Directive Information Content Entity."
should be:
"A Material Copy of a Barcode that is designed to bear parallel lines of varying widths and spacing that concretize some Directive Information Content Entity."
|
@mark-jensen Thanks for the comments Mark. I've just committed an update to address. |
APCox
added
the
for 2.1 release
|
EDIT: Please see post below breaking these items into more actionable tasks. A number of topics were raised by the CCO WG: Related to this PR and especially to the proposed class ‘Media Content Entity’, review 'Act of Communication by Media' and its relationship to 'Act of Communication by Mass Media' and their contents’ relationship to the definition of the new class ‘Media Content Entity’. What does "canonical" mean in ‘Media Content Entity’ =def ‘An information content entity presented in a canonical media format’. Clarify that "presenting" in the above definition means "showing/displaying a concretization". This may mean that ‘Media Content Entity’ is better represented as a subtype of 'Representational ICE'. If all content is conveyed via some media, then we should ask "What information would not fall under the ‘Media Content Entity’? If all ICEs fall under this class, we need to rethink it. Cross reference the proposal for 'Information Structure Entity' in issue #596 . Regarding item 'G' above, some of these IBAs may be better represented as 'Information Medium Artifact' instead, e.g., Book, Database, and Spreadsheet. As they are currently defined, there are no blank or empty artifacts of these types. Switching them to be IMAs would enable greater nuance. |
APCox
added
the
Reviewed by CCO WG
|
@APCox I think it is clear that not all ICEs are conveyed/presented by a canonical media format because some ICEs are not convey/presented at all. The obvious examples are ICEs carried by brains. Next, in addition to needed clarification on "canonical," I think clarification on "media format" would also be helpful. Is this supposed to be interpreted as a kind of information structure (GDC) or something else? Minimally, it would be helpful to have a list of examples of canonical media formats. As for B, why aren't we just editing the definitions such that 'carries' is used where 'bears' currently is imprecisely used? Are legacy considerations so powerful that continuing to misuse a term is preferable to fixing it? |
|
Many of these comments are open-ended questions or meeting notes and, in my opinion, appear to be best handled by opening a discussion thread or a new issue and executing a second PR once this one is merged. In response to questions about 'canonical, I have added a comment on ‘Media Content Entity’ that attempts to unpack the intent. Of course, this could be improved upon, but like other matters raised here, consensus on the improvement will likely not be achieved on this review. Nonetheless, this PR offers an improvement on CCO as it exists today and hence I'd recommend we move forward and address additional improvements in further rounds of work. @johnbeve @mark-jensen |
|
Can you remove media content entity, which goes beyond fixing things and introduces something new, and not yet well thought through? |
|
@alanruttenberg This class with this definition was agreed to by @mark-jensen @johnbeve @APCox on May 2nd. It was proposed in response to a part of your comments here, which left the parentage of these classes unclear in a way we did not prefer: #564 |
@avsculley The definitions were edited in this way. For example:
|
This is a good reason to not worry about:
Because the premise (or more accurately, the antecedent as it's written above) is false. |
|
Converting the WG meeting notes from above into action items:
Created issue #680 to address this outside of the current PR.
This is relevant to approving this PR. Please review the comment added to
This is relevant to approving this PR and may be addressed via a comment added to
As noted by Alec above, this does not appear to be an issue.
Created issue #681 to address this outside of the current PR.
Created issue #682 to address this outside of the current PR. |
|
@avsculley If the only exception to media content entity is concretizations in brains, then it makes more sense to make those a class. But the problem with that and media content entity is that if you look at all concretizations of an ICE you would be hard pressed to find classes of them that aren't both concretized as media content entities AND brain concretizations. Or whatever other non-media content entities there are. And even if you could, I predict that there will be multiple inheritance problems. Format is a distinct axis, and I think the right solution is to have information structure entities an then make defined classes in terms of those. What you need to be able to talk about, IMO, if you want to talk about this stuff, are something like subsets of concretizations. For a particular ICE there possibly be some subset of concretizations that are formatted "canonically" as well as other interesting subsets. I'm mixed about whether we should consider those subsets "sub-ICEs" or represent them as classes of concretizations. We want something along these lines because I think it is important to be able to talk about sensory-perceived concretizations vs digital concretizations. They have different properties. Right now if I have some sentence that is an ICE the concretizations would include both, and it's not quite the same to talk about, say, text being in a font for digital entities. When in a digital concretizations of a text, the digital versions are more like directives. It makes sense to talk about what "serif" means when talk about visual concretizations, and somewhat less meaningful when font is just an instruction. |
|
@johnbeve Per our conversation Friday, please provide some language for inclusion for 'presents'. |
|
@alanruttenberg I don't think brains-as-carriers is the only counterexample. There are also ICEs presented in non-canonical media formats, and ICEs that are not presented and also not carried by brains. I'm thinking of ICEs carried by computers here. |
|
@avsculley Do you agree that this is something that is a matter of concretizations, rather than an issue of ICEs? Given that most if not all ICEs can be concretized in multiple ways. |
|
@alanruttenberg Yes I agree.
|
|
@neilotte continuing my review, why did cco:ont00001209[UPC-E Barcode] get deleted and replaced with cco:ont00002049? |
belongs in Information Entity Ontology.
sublcass restriction was originally declared in artifact ontology, PLUS the parent class was supposed to be changes from ICE to 'media content entity'
Fixing minor errors and to improve diffs
|
@mark-jensen Good catch. Dropping ont00001209 appears to have been a copy-paste error. Just committed a fix restoring it. |
|
The governance board members have discussed this pull request and agreed to approve it and then iterate to address the concerns that have been raised through additional pull requests that address each issue. |
src/cco-modules/ArtifactOntology.ttl
Outdated
| cco:ont00001760 "https://www.commoncoreontologies.org/ArtifactOntology"^^xsd:anyURI . | ||
|
|
||
|
|
||
| ### https://www.commoncoreontologies.org/ont00002038 |
There was a problem hiding this comment.
@neilotte cco:2038 is curated in the Information Entity Ontology
a. For IBA and IBE, add the alternate labels ‘Information Carrying Artifact’ and ‘Information Carrying Entity’, respectively, and add the comment to IBE: ‘This class continues to use the work ‘bearing’ in its rdfs:label because of potential confusion with the acronym ‘ICE’, which is widely used for information content entity.’
b. Add a similar comment for IBA that indicates by “bears” we mean that the IBA ‘is carrier of’ an ICE.
c. IBA should get the comment: “This class continues to use the word ‘bearing’ in its rdfs:label for legacy reasons. It is understood that an IBA bears the concretization of an ICE and not the ICE directly.”
d. Update all rdfs:labels of subclasses of IBA to use prefix ‘Material Copy of’ and make their existing rdfs:label an alternative label. For instance, the class ‘Book’ will have the rdfs:label ‘Material Copy of a Book’ and the alternative label ‘Book.
e. Create a subclass of ‘Information Content Entity’ called ‘Media Content Entity’ with the definition ‘An information content entity presented in a canonical media format’.
f. Ensure the entire IBA subclass directory is then copied under ‘Media Content Entity’ such that, for example, the class ‘Book’ is now an ICE.
g. Add a subclass axiom on to each IBA classes which declares each ‘is carrier of’ some . For instance, every ‘Physical Copy of a Book’ is a carrier of some Book’.
h. In both the IBA and the ICE hierarchy, ensure that Book, Journal Article, and Spreadsheet (in both senses) are under ‘Document’ (again, in both senses).
i. Update the rdfs:label of ‘Document’ to ‘Document Content Entity’
j. Rename ‘Document Form’ to ‘Form Document’
k. Place ‘Document Field Content’ under ICE and add that is a continuant part of some Document. Add the alternative label ‘Document Field’.
l. Move ‘Document Field’ from under IBE and place under IBA. m. Review all definitions of every class affected here to ensure the definitions clearly describe either ICEs or IBAs (e.g. a relationship like ‘is carrier of’ or ‘represents’ is not used inappropriately within one of these definitions).