Adding Subtypes for

[GullyAPCBurns]

In the latest release of OBI, there are large number of categorical value specifications for tumor grade.

Can we add a term for 'Tumor Grade Value Specification' to group these together?

[cstoeckert]

Have discussed this with Helena Ellis (BIobanking without Borders), Anna Maria Masci (Duke), and Shannon McCall (Duke) to identify most useful classifications for pathologists and biobankers. Our consensus is to create these terms: cancer value specification: A categorical value specification that is based on rules for assigning values to describe the presence and progression of cancer. examples of usage: tumor grade, AJCC tumor stage AJCC defined value specification: A cancer value specification defined by the American Joint Committee on Cancer. colon cancer stage value specification: A cancer value specification defined for characteristics of a colon specimen. Equivalent class: ‘cancer value specification’ and ‘part of’ (some ‘categorical measurement datum’ and ‘is about’ some ‘colon specimen’) kidney cancer stage value specification: A cancer value specification defined for characteristics of a kidney specimen. Equivalent class: ‘cancer value specification’ and ‘part of’ (some ‘categorical measurement datum’ and ‘is about’ some ‘cortex of kidney specimen’) lung cancer stage value specification: A cancer value specification defined for characteristics of a lung specimen. Equivalent class: ‘cancer value specification’ and ‘part of’ (some ‘categorical measurement datum’ and ‘is about’ some ‘lung specimen’) ovary cancer stage value specification: A cancer value specification defined for characteristics of an ovary specimen. Equivalent class: ‘cancer value specification’ and ‘part of’ (some ‘categorical measurement datum’ and ‘is about’ some ‘ovary specimen’)

[jamesaoverton]

Discussed on 2018-03-19. There's concern about the label "cancer value specification" is too broad. Some suggestions: "cancer stage value specification", "cancer diagnosis value specification"

[Aqua1ung]

Regarding making "tumor grade value specification," or "cancer stage value specification" (or whatever it may end up being dubbed), entities as opposed to (custom-designed) datatypes: I know that in the past I made the same point vis-a-vis datatypes versus entities in general, but I just could not find the time to provide the code for that. If the blocker was the absence of code, let's hope that this below will remove all blockers form adopting datatypes as value specifications, at least for scalar value specifications:

• in Turtle: _:bn rdf:type rdfs:Datatype . _:bn owl:oneOf("pT4" "pN2" "G1" "G2" "G3" [etc. etc. etc.])

• in Manchester syntax: {"pT4", "pN2", "G1", "G2", "G3" [etc. etc. etc.]}

(Surely, this does not necessarily have to be a blank node, so it can be a fully named datatype.)

I am specifically looking for a reason to choose "entity" over "datatype" other than (a) "we need to use these value specifications in subject position" (this could be easily worked around), and (b) "that is how we've chosen to represent value specifications so far, and it would be awkward to turn around at this point in time."

[jamesaoverton]

We discussed OWL Datatypes before #868. I've still never seen them used in the wild. Can you point to an example?

[cstoeckert]

This issue is NOT about whether there should be value specifications. Please restrict comments here to the proposed terms for grouping value specifications.

[Aqua1ung]

Yes Chris, no one says that value specifications should not be. The issue is an implementational one: value specifications (and especially scalar ones) can be represented in two ways: (1) as entities, and (2) as datatypes. I was asking for a reason why entities (which are quite expensive from a representational point of view) are more advantageous vis-a-vis datatypes (which are a lot cheaper representational-wise).

[bpeters42]

CC: The burden is on you to prove why we need to change previous design decisions. It is not at all clear how you quantify that entities are more 'expensive'. At least we know how to deal with them. I would not know, for example, how to query for datatypes that are the output of mass spectrometry experiments, and how to reason to distinguish quantitative vs. Qualitative ms data.

On Tue, Mar 20, 2018, 9:34 AM Cristian Cocos notifications@github.com wrote:

Yes Chris, no one says that value specifications should not be. The issue is an implementational one: value specifications can be represented in two ways: (1) as entities, and (2) as datatypes. I was asking for a reason why entities (which are quite expensive from a representational point of view) are more advantageous vis-a-vis datatypes (which are a lot cheaper representational-wise).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/obi-ontology/obi/issues/879#issuecomment-374666148, or mute the thread https://github.com/notifications/unsubscribe-auth/ANN9IoJDNeLzlutp4CNrHpaWxLZyXJ0-ks5tgS-RgaJpZM4QcVw1 .

[Aqua1ung]

Apologies to those who think I hijacked the thread, I did not realize that my post could be construed as such. I will move the discussion back to the old #868 ticket.

[cstoeckert]

Closing this as there has not been further need for grouping these terms. Can reopen if that changes.