Update ArtifactOntology.ttl

[neilotte]

Addressing #160 .

I performed a scan of all IBEs that are said to bear some subrelation of aboutness and revised the wording.

[neilotte]

@cameronmore Mind taking a look at this one when you have a moment?

[cameronmore]

Agree but hesitant about the definition of chart.

[alanruttenberg]

This shouldn't be done separately from the IBE/ICE refactor, which is being worked on in the CCO weekly grad student weekly, in particular by at least @avsculley and myself in the https://github.com/CommonCoreOntology/CommonCoreOntologies/tree/ice-iba-refactor. Let's coordinate.
It doesn't really deconflict in that e.g/ Chart probably shouldn't be in IBE at all.

[neilotte]

@alanruttenberg I was executing here only to update the definitions and not the broader of issue of what should and shouldn't be an IBE. Good to know you've been tackling this more comprehensively; however, I see your branch is now 35 commits behind--can you and @avsculley pull from development? Also, are @APCox @johnbeve and @mark-jensen tracking this refactor?

[alanruttenberg]

I believe they are aware. It is a WIP, but if not they are now :-)
Agree it should pull to update. But it should be noted that it isn't exclusive to us (there are already other students involved in requirements gathering) and I am hoping for wider participation in the discussion. Since it is a big change, it needs to be coordinated, which is the main point I wanted to make.

[alanruttenberg]

To be clear, I don't think these changes should be made now/here. They suggest progress on the IBE/ICE issue that isn't in sync with current thinking. It is an open question as to whether or not to retain a corresponding IBE terms for each ICE term. For example, it is rare to have an IBE chart about which we want to say something interesting. An example of where we might use such a term might be in referring to an original historical chart for which there is one copy. Or if access to specific printed copies of a chart needed to be tracked, though I would expect such tracking to be at a higher level like document.

[neilotte]

@alanruttenberg "They suggest progress on X that isn't in line with current thinking, where current thinking considers X an open question" --seems like a recipe for the perfect murdering the good.

Can you give me an ETA for when your branch will be ready to merge in? We're planning to release a 1.6 just to get this repository looking respectable (maybe in the next month), and then a major 2.0 release where we seek truth and justice and break some things. Would you target the first or the second for this update?

[avsculley]

I recently got a new job at SKS and haven't stayed on top of this. But I can set time aside this weekend to make sure that the work we've done is both consistent with the most recent updates to CCO, and also suitable for viewing. Currently, the ICE/IBA refactor work is too tangled up with work on information structures that we were also doing. We decided to separate them since the ice/iba refactor stuff is more straightforward, and, if the community wants it to be implemented, could be ready much sooner than work on information structures. This became even more apparent in the recent NCOR CCO working group session on information.

…

________________________________ From: Alan Ruttenberg ***@***.***> Sent: Monday, August 5, 2024 9:33 PM To: CommonCoreOntology/CommonCoreOntologies ***@***.***> Cc: Alec Sculley ***@***.***>; Mention ***@***.***> Subject: Re: [CommonCoreOntology/CommonCoreOntologies] Update ArtifactOntology.ttl (PR #319) To be clear, I don't think these changes should be made now/here. They suggest progress on the IBE/ICE issue that isn't in sync with current thinking. It is an open question as to whether or not to retain a corresponding IBE terms for each ICE term. For example, it is rare to have an IBE chart about which we want to say something interesting. An example of where we might use such a term might be in referring to an original historical chart for which there is one copy. Or if access to specific printed copies of a chart needed to be tracked, though I would expect such tracking to be at a higher level like document. — Reply to this email directly, view it on GitHub<#319 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ATJNTNYK7OQNGL7IIYMCQEDZQARU7AVCNFSM6AAAAABL7K4X52VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENZQGE4TKMZZGM>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[neilotte]

Thanks @avsculley!

[alanruttenberg]

If you are aiming for 1.6 soon then I would make the IBE/ICE changes in 1.7. As I said, I don't think this pull cleans anything up, because the major flaws remain and these changes don't move in the direction changes are going to happen, so they aren't making progress, IMO. I say 1.7 because the change will require several people to review and because we haven't made one of the decisions, namely whether or not to keep all corresponding IBE terms or deprecate most of them. I lean towards the latter. If that many deprecations happens it might be polite to give a longer warning. Which reminds me that we really need a discussion list or two. Probably a general questions and discuss list as well as an announce list, for messages like: There's a new release and maybe for the deprecation (though in the latter case requesting comments, if any, get directed to the discuss list). If a mailing list is set up, please make sure it has a public archive. Google groups is easiest. There's a milestone capability in Github. I haven't used it but it might be worth looking into for planning things like this.

[neilotte]

@alanruttenberg Certainly agreed on the need for a listserv, foreshadowing, and the rest of it. I'd like to spend some time finding the best options here and not the biggest fan of google groups. Certainly github has a lot of bells and whistles too that we've only scraped the surface of.

On the matter of this change: I hear you, but I disagree. I think fixing these definitions aids in clarifying that these are not ICEs and that this will be marginally helpful to users in the interim between now and whenever the larger and more important matter is settled.

[alanruttenberg]

We agree to disagree. However I believe we aim for consensus. I don't think my claims unreasonable, and I have been spending time working in this area.

[neilotte]

Hey Alan, can we maybe discuss briefly over the phone? Can be whenever.

[avsculley]

I'm still working on the refactor. It should be coming sometime this week.

[johnbeve]

...ordered sequence of Information Bearing Entities that bear...

We should change "bears" to "carries" since the range of bearer of is SDC.
A List in the sense intended here (from the Wiki citation) allows for empty lists. Presumably, the carriers involved in an empty list are not always multiple IBE_s_. The definition entails they must be. Note, a mathematical sequence can have a single member and still be ordered, e.g. partial order.
The definition of Code Identifiers requires they consist of a string of characters. Whitespace is an ASCII character, but not a string of character_s_.

Improvement?
A List that consists of one or more IBEs that carry Code Identifiers and are the subjects of some Sequence Position Ordinality

[johnbeve]

Following on the CodeList suggested revision:

• List - An Information Bearing Artifact that consists of one or more Information Bearing Artifacts that carry Information Content Entities and are the subjects of some Sequence Position Ordinality.

[johnbeve]

Suggested revisions to parent and subclasses:

• Barcode - An Information Bearing Artifact that is designed to bear one or more geometric shapes that concretize some Directive Information Content Entity.

• One-Dimensional Barcode - A Barcode that is designed to bear parallel lines of varying widths and spacing that concretize some Directive Information Content Entity.

• Two-Dimensional Barcode - A Barcode that is designed to bear lines of varying widths, spacing, height, and color that concretize some Directive Information Content Entity.

[johnbeve]

I agree with @alanruttenberg on the need for refactoring; I'm not exactly happy with the IBE subclasses...I'm looking eagerly towards @alanruttenberg's and @avsculley's results.

Even so, I'm inclined to update these IBE definitions (see my proposed revisions to @neilotte's updates) because the original definitions exhibit serious confusions, e.g. an information bearing entity can't represent. I'm worried that these confusions - if left unaddressed - will spread among new users who might be leveraging CCO before the refactoring is implemented.

With respect to these updates suggesting progress on the IBE/ICE issues that aren't aligned with current thinking, perhaps we can make it clear here and elsewhere that:

• IBE/ICE refactoring is being researched
• These updated classes may not persist through the refactoring
• They're being updated nonetheless because of internal issues with the definitions, independent of the refactoring effort

[neilotte]

@johnbeve Ready to review.

[mark-jensen]

I agree with @alanruttenberg points re making changes here when there is good likelihood that they will be superseded by the much more comprehensive refactor of ICEs and IBA/Es in CCO. However, the timeline to completion and adoption is uncertain. Which makes sense. The refactor is requiring taking a more definitive stance of the nature of GDCs and ICEs. It will be a substantial update to CCO and require a decent amount of vetting by the community.

These changes reflected in this MR are small improvements, they are needed ones, the work has already mostly been done (see my suggestions), and I think they will transfer nicely into the ongoing refactoring efforts to move IBAs up and over to ICEs. Therefore, I approve them, as short-lived as they may be.

[johnbeve]

@neilotte, I'm on board with @mark-jensen's re-revisions and I believe the revisions overall address @cameronmore's concerns as well.

Folks on the thread agree refactoring is needed and we're looking forward to seeing what @alanruttenberg and @avsculley have done. The majority seem in favor of making these minor updates while waiting for the more substantial work to come.

I believe we all agree that these minor updates should not suggest to anyone that more substantial revisions to the information content in CCO are undesirable. We're simply revising terms in CCO that exhibit obvious issues while awaiting more substantial revisions.

So, barring further objections, I'm happy to approve this PR once the latest updates have been made.

FYSA @APCox @oliviahobai

These changes have been made and separately reviewed by Mark.

These changes have been made and separately reviewed by Mark.