Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is this an appropriate use of 'extends' on the ‘sourceDataSet’ property of a StudyResult in the core-im? #136

Open
mbrush opened this issue May 28, 2024 · 2 comments
Assignees

Comments

@mbrush
Copy link
Contributor

mbrush commented May 28, 2024

A sourceDataSet property is defined for the StudyResult class that extends the derivedFrom property of its parent InformationEntity class. This is indicated using an `extends: derivedFrom' element.

image

Is this an appropriate/valuable approach in this situation (to define a more specific property that defines more precise semantics and constraints? IMO it is important to constrain the value of this property to be a DataSet, so minimally I think we would want to extend derivedFrom to add this, but we could keep the same name (if this is more appropriate?).

@mbrush mbrush changed the title core-im: appropriate use of 'extends' on the ‘sourceDataSet’ property of a StudyResult? Is this an appropriate use of 'extends' on the ‘sourceDataSet’ property of a StudyResult in the core-im? May 29, 2024
@larrybabb
Copy link
Contributor

@mbrush I'm not 100% clear on what you are suggesting above.

I think the way sourceDataset is defined it is extending derivedFrom and constraining it to use the more precise DataSet data type versus using InformationEntity.

Are you simply saying that StudyResult.sourceDataset should not renamed back to StudyResult.derivedFrom? If that's the case then it is a simple change. We can always override that name in the implementation profile if we feel derivedFrom is not clear enough.

If you are suggesting something else, please clarify.

@larrybabb
Copy link
Contributor

@mbrush I made a comment about this in issue #159 which I believe is vital to resolving this in the end. Please review #159 and consider closing this to continue the discussion there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

No branches or pull requests

2 participants