Definition of http://www.ontologyrepository.com/CommonCoreOntologies/biologicalsex

[jimschoening1]

This issue is moved from IEEE Gitlab CCO at https://opensource.ieee.org/cco/CommonCoreOntologies/-/issues/156

It was posted by [Ted Thibodeau Jr]

http://www.ontologyrepository.com/CommonCoreOntologies/biologicalsex arose in w3c/vc-data-model#963
It was part of the description of a human, as --

"biologicalsex": "F"

As I said in the GitHub issue where this arose --

Boy-oh-boy (no pun intended), is biologicalsex) fraught with peril. How are F and whatever alternative values exist defined? I'm pretty sure [you] planned to handle entities assigned "Female" ([typically] XX) or "Male" ([typically] XY) at birth (though I bet [you] don't actually require that the chromosomes be checked), but what about XXY, X, and other variants yet to be discovered? A world of dangers awaits!

@james.schoening pointed me here to continue the discussion....
The current definition of BiologicalSex is

A Quality inhering in a bearer by virtue of the bearer's ability to undergo sexual reproduction in order to differentiate the individuals or types involved.

That "definition" is difficult to decipher, at best, and makes little sense given the value in the example ("F") which seems most likely to stand for "Female" by which you might intend to mean a being which contributes an egg to the reproductive process, as opposed to an "M" which might contribute sperm or similar. But what of a being which may contribute both in a single reproductive action? Or which may contribute one at one time and the other at another time? Or....
Ontologies should always include rdfs:domain and rdfs:range, or at least schema:domainIncludesand schema:rangeIncludes. This is especially true in cases like this, where it appears there is meant to be a limited number of values, but as I said above, there ought to be at least 4 potential values (to handle humans with XX, XY, XXY, and X chromosomes), probably more (to handle other biological entities which may have different chromosomal attributes, and/or be hermaphroditic and/or capable of changing sex characteristics, among other considerations).

Response by

Ronald Rudnicki
@rudnicki
· 1 year ago
Owner
Our definitions of Female Sex and Male Sex were taken from the Phenotypic Trait Ontology. The links in the ontology file are broken, but these should work. https://bioportal.bioontology.org/ontologies/PATO/?p=classes&conceptid=http%3A%2F%2Fpurl.obolibrary.org%2Fobo%2FPATO_0000383 and https://bioportal.bioontology.org/ontologies/PATO/?p=classes&conceptid=http%3A%2F%2Fpurl.obolibrary.org%2Fobo%2FPATO_0000384 .

These classes are subtypes of the Phenotypic Sex. If you look under the Genotypic Sex class I think you'll find consideration of the cases you mention.

I propose that we expand the class of Biological Sex to mirror that of PATO. Please consider that proposal and reply with your judgement.

Response by:
Ted Thibodeau Jr
@macted
· 1 year ago
Author
I'm not sure what you mean by "expand the class of Biological Sex to mirror that of PATO". If you mean, bring the entirety of PATO's Biological Sex, including all contained therein, that would certainly be an improvement. I'll say a bit more, in case that's not what you meant, and also because I think that should be just one of at least a few (probably many) steps, related to all CCO inheritance from external ontologies.

Cherry-picking terms and/or definitions from someone else's ontology is not generally recommended, especially when (as it appears) their ontology is not fully understood. The maintainers of the Phenotypic Quality Ontology (PATO) clearly took great care in its design (even if it remains imperfect), and for reasons that entirely escape me, those who have been working on the Common Core Ontologies apparently decided that only a tiny fraction of PATO was worth inheriting.

At a minimum, I would adjust the definition/description in the CCO to include the details you provided here — especially that your BiologicalSex could probably have been better named PhenotypicSex (and I would recommend that change if your ontology is still sufficiently fluid).

I would also encourage CCO to work with PATO to improve their definitions/descriptions. In immediate focus, "The bearer's ability to undergo sexual reproduction in order to differentiate the individuals or types involved" remains cryptic (indecipherable, really) to me, as "sexual reproduction" does not "differentiate the individuals or types involved"; "sexual reproduction" produces offspring of the individuals participating in that "sexual reproduction".

[TallTed]

I am that Ted Thibodeau Jr, known in some places as @macted, and here on GitHub as @TallTed.

I suggest and request that the content of the original post & comments on opensource.ieee.org be recopied and pasted into the initial comment above, such that all the formatting, links, etc., are preserved (as the plaintext version currently above doesn't deliver all the relevant info, which makes it harder if not impossible for new readers to fully understand). If you cannot do such, I can do it in a comment below, and would then ask that the initial comment above be edited to nearly nothing, in favor of the fully marked-up version.

[johnbeve]

@TallTed Is anything missing presently? The links are working but I can't see the original.

[jimschoening1]

@TallTed. Glad you somehow got notified of how I moved your issue to this new Issue Tracker, since the duplicate one is being shut down. I just now inserted the links. I'll also see if I can find any volunteers to address your Issue, which obviously goes deeper than the original definition. Thank you for this submission.

[mark-jensen]

@TallTed Converting this to a discussion per new policy. The conversation can be taken up there.

[TallTed]

Ugh. This is a terrible "new policy" and I strongly urge that it be reconsidered.

GitHub "Discussions" are a poorly implemented reinvention of a Q&A site (a la StackOverflow, Reddit, etc.). One "question", unlimited "answers" always in chronological order, with unthreaded comments on each "answer". No deeper threading. No way to see "comments since {date}", nor "comments since {last view}", nor any way to re-order the answers according to "most recently commented", etc., etc.

Note, for an obvious example, that once I post this comment, this "question" will have 4 "answers", only one of which can really be considered an "answer" to the "question" (which cries out for reformatting to better present the mini-thread it contains), i.e., all 4 comments to date should be presented as a minithread in response to that "question".

I'm sure this is not the best thread for these comments, but it's the thread that involves me, so it's where I'll comment unless/until explicitly pointed to the thread where feedback on this "new policy" is best aimed.

[johnbeve]

@TallTed:

• You seem to be comparing what you'd like to see in a forum against GitHub Discussion. The new policy you reference was to shift from using the GitHub Issue Tracker - which doesn't have the features you desire either - to GitHub Discussions. I see this shift as an improvement, even if it falls short of what you'd like to see in a discussion board.
• GitHub Discussions actually provide several of the features you desire, such as threading (as evidence by this response). If you're looking for an answer to a question, there is a "Q/A Discussion" feature that will allow you to accept an answer as adequately addressing whatever question you have.

You'll then have to forgive me if I'm unmoved by your remarks.

If you have an alternative proposal to hold discussions, I'd be interested in hearing. Presently, I'd prefer not to continue with the previous practices of having open discussions on the Issue Tracker. Because open discussions in the CCO repo have rarely been tied to any actionable outcome, pull request, etc., they have tended to remain open and ignored for years. Better, I think, to reserve the Issue Tracker to, as the GitHub documentation suggests:

• Keep track of tasks, enhancements and bugs.
• File a bug report.
• Share feedback about a specific feature.
• Ask a question about files in the repository.

If you believe your original comment is more appropriate as an Issue, then please explain. As it stands, I am not sure exactly what recommendation you were making a year ago, if any.

[neilotte]

@TallTed I'm sorry this move is a concern. The developer team's move to using the discussion board is motivated by the need to sort targeted requests and related tasks that are immediately actionable from matters that require discussion (see also the Communications policy for Github). This has been critical in allowing us to identify actionable requests we can plan releases around and distinguish them from important but ongoing discussions the CCO users on this forum need to have.

We share your concern that the discussion forum should not be "a poorly implemented reinvention of Q&A". We plan to return to an organization of the discussion board in the coming weeks to ensure discussions have direction, that they are guiding agendas in multiple forums (e.g. IEEE, the ncor office hours), and that they result in well communicated outcomes (and not just the "four answers" dead end you mention). One of the outcomes of this move is also the discovery that multiple discussions were occurring on separate 'issues' going back for years. We hope to use the discussion board to more effectively encourage consolidation of these threads. Expect further changes here.

Apologies for further stepping on @jimschoening1's thread (which already concerns an important topic). If there's more to discuss here, let's start a separate thread under General.

[TallTed]

Apologies for further stepping on @jimschoening1's thread (which already concerns an important topic). If there's more to discuss here, let's start a separate thread under General.

Note that this important topic is really my thread, which I originally started on IEEE Gitlab CCO, from whence it was moved to GitHub CCO by @jimschoening1, from whence it was moved here, again by @jimschoening1.

[alanruttenberg]

I've already communicated this to @neilotte but mentioning here for the record. I concur with @TallTed . Many of the "discussions" are really issues that need to be resolved the same as any other issue, and the organization of the issues could have been better accomplished by judicious use of labels. This gives the appearance that there are fewer issues, but only the appearance.

[johnbeve]

If there are issues that have been moved to Discussion inappropriately, then I agree this should be remedied. I see this as growing pains though, and not a mark against distinguishing issues from discussions.

[johnbeve]

I would like to note my position here too for the record. I am strongly in favor of moving conversations from the Issue Tracker to Discussion when they are:

• Not necessarily related to specific files in the repository.
• Open-ended conversations.
• General announcements to the community.
• Specific questions seeking specific answers.
• Polls.

The CCO Issue Tracker has - for several years - been an open forum for any and all discussions, complaints, announcements, etc. Many issues have remained open and untouched for years, cluttering the tracker, which - as a counterpoint to @alanruttenberg's remarks - has given the appearance that there are more issues than there are. That, is only an appearance.

But this cleanup is not merely for the sake of appearance. There were numerous issues on the tracker that until recently were open despite the initial fix or update having been addressed already, since the meandering open-discussions either obscured the fix or raised unrelated issues that themselves had not been addressed. Certainly we agree issues can be managed better. A natural way to approach better issue management is by distinguishing issues from discussions.

I understand GitHub Discussion as a place - broadly speaking - to mature ideas, requests, updates, etc. so they are actionable. Once actionable, such updates would make it to the issue tracker, PR, evaluation, then merge once vetted.