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

document stereotype issues #41

Open
bnlawrence opened this issue Oct 10, 2019 · 0 comments
Open

document stereotype issues #41

bnlawrence opened this issue Oct 10, 2019 · 0 comments
Assignees
Labels
cimv3 For consideration in a major release metamodel Things which are about how the python definition language works and/or what it requires.

Comments

@bnlawrence
Copy link
Member

bnlawrence commented Oct 10, 2019

We have a number of places in the ontology where we either have two versions of the same structure, one of which is a document, and one of which is not (e.g. software.software_component and software.implementation). The idea I think was to ensure that the latter are composed, and the former are linked. We also have places where the clear outcome is that some documents should be composed in and some should be linked.

In the case where documents are composed in, the intention is that the "internal" documents are subject to the parent's life cycle, that is, they don't need their own doc_meta_info.
One assumes in those cases there is no reason for external documents to link to them either.

At the moment, implementations can choose whether to replace attribute values with linked_to stereotypes with a doc_reference instance or an actual instance of the target document type. In the latter case, many documents are serialised into one json document.

Is there a case for allowing document instances not to hold meta info in the instance where they are composed? Allowing this would encourage specialisations to choose composition in some cases, and it would mean we could remove the first case of repeated attributes with document and non-doc versions.

This could be a metamodel issue.

@bnlawrence bnlawrence added cimv3 For consideration in a major release for paper Need to be addressed before core paper publication metamodel Things which are about how the python definition language works and/or what it requires. labels Oct 10, 2019
@bnlawrence bnlawrence self-assigned this Oct 10, 2019
@bnlawrence bnlawrence removed the for paper Need to be addressed before core paper publication label Jan 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cimv3 For consideration in a major release metamodel Things which are about how the python definition language works and/or what it requires.
Projects
None yet
Development

No branches or pull requests

1 participant