clingen-data-model / clingen-interpretation

Allele (variant) interpretation model and API for ClinGen
3 stars 1 forks source link

UserLabel #211

Closed cbizon closed 6 years ago

cbizon commented 6 years ago

Is UserLabel still meant to exist? My understanding is that we were removing it...

larrybabb commented 6 years ago

good question for @bpow and @mbrush .

I think it is still needed. but I'm not really sure.

larrybabb commented 6 years ago

larry will fix the 3 userlabel examples to assure that the "labelFor" property and its referenced attribute are in the examples correctly.

larrybabb commented 6 years ago

@cbizon @mbrush Heads up. I started to look at correcting the way the 3 "ascertainment" UserLabel examples in our sheets should be structured and I realize that it follows the 4th approach in Matt B's doc which deals with a curator extending a value set locally with a blank node.
Or it could be like the 2nd approach as we discussed on our call today, if we where to create a SEPIO ascertainment concept for something like "custom ascertainment" and presume folks will use this and the apply the UserLabel approach to describe it.

I sort of like option 2, but I need @mbrush and @cbizon to weigh in on whether we should/could include concepts in our controlled value set lists for things like "custom" or "other" with the idea they would be used to allow systems to simply capture a user's description. If not then we only have one way for systems to share this kind of exceptional stuff.

I could make the argument that there are "custom" ascertainment methods and it is sort of fruitless to have folks try to label them all. Yet, it is important to capture the "description" of the custom choice. This pattern could be useful for a lot of things.

Anyway, please weigh in and direct me to use approach 2 or 4 or something else, please.

larrybabb commented 6 years ago

let's discuss and resolve this with #221 on tomorrow's call.

mbrush commented 6 years ago

If I understand, this is an interesting proposal to create an 'other' value in value sets and let users select this, and create a user label and description that describes their new concept.

This doesn’t require creation of a new iri - be it a bnode or a new proper IRI - the way the other proposed approaches for allowing users to create 'new' terms in the data instead of using existing values from a value set.

This could be a generally useful design pattern that we choose to document, and even use to replace these other methods requiring users to create local iris - which may be perceived as an impediment for some.

Looking forward to discussing on the next call.

larrybabb commented 6 years ago

We discussed and kept it as a useful pattern. It is available in our example data in 3 instances of Ascertainment values for population allele frequency statements. In all 3 cases, we only use the new generic "description" attribute which descends from the ancestor Entity type that also contains label.