[DDI-SRG] [MRT] Open model issues for decision

[Flavio Rizzolo]

Unfortunately, I won't be able to make it tomorrow. I'll write my 
proposal here as a reference.

I think our only priority now should be to make the XSD work and get the 
spec in place. The best way to do that is to have a separation of PIM 
and PSM. For now, it could be just a separate copy, not ideal but 
practical. That means we make changes to the PIM when the change is 
conceptual, i.e. platform independent, and we make changes to the PSM 
whenever it's purely about the XSD, i.e. platform specific. Linking the 
Process Model and the Data Description is conceptual, so it goes into 
the PIM. Adding ids to classes that should not be referenced directly, 
i.e. the plumbing, as Larry said, should be done in the PSM because it's 
only needed in some syntax representations. The reason for having these 
two models is the same as always: separation of concerns. I understand 
the tight timeline, so that's why we'll do it by hand rather than by a 
proper set of automated rules. The alternative, pilling everything up in 
a single model, impacts documentation, diagrams, and other 
implementations in the future. Besides, it doesn't even save us time now.

It seems to me the only real problem at hand is that the XSD needs some 
ids that are not in the PIM. Hence, we add ids as necessary in the PSM 
to get a working XSD. Just a single id attribute. Easy. If in the 
process we find something conceptual to fix in the PIM, e.g. a missing 
association, we fix it there as well. Easy again.

Now, keeping in mind the tight timeline, the issue about identification 
and annotations we discussed is not actually breaking the XSD, so it 
shouldn't be a priority. If it can be done, great. If not, we flag it 
and do it after the review.

In any case, whether we do it one way or the other, for sure we 
shouldn't add identification to the plumbing in the PIM. Some classes do 
not have identification by design. It's not a bug. Adding ids and a 
whole bunch of identification content to classes in the PIM that don't 
need it, e.g. Position in a List, or InstanceValue, would be overkill, 
unnecessary, and wrong.

In fact, it would be like changing the directions of associations in the 
PIM just because the XSD needs them. I refer the reader to this Jira 
issue related to this topic:

https://ddi-alliance.atlassian.net/browse/DMT-319

/_Hence my proposal_: add a simple id attribute, say a String, to the 
PSM classes that don't have ids to get a working XSD. Then, change the 
overall identification approach when everything else is working, time 
permitting. /

That way, we can have the necessary time to get a Process model working 
and other parts of the PIM that might need fixing.

Flavio


On 05/02/2020 11:27 a.m., Hilde Orten wrote:
>
> Achim,
>
> To my understanding point 1. to 3. were not discussed, and no firm 
> agreement on 4. and 5.
>
> Point 1. seems to be agreed in the emails?
>
> Talk to you tomorrow!
>
> Best wishes,
>
> Hilde
>
> *From:*ddi-srg-bounces at icpsr.umich.edu 
> <ddi-srg-bounces at icpsr.umich.edu> *On Behalf Of *Wackerow, Joachim
> *Sent:* onsdag 5. februar 2020 17:14
> *To:* DDI - Structural Reform Group <ddi-srg at icpsr.umich.edu>
> *Subject:* Re: [DDI-SRG] [MRT] Open model issues for decision
>
> Was there agreement on any of the open issues in the list below?
>
> If yes, I could continue to work on this.
>
> Achim
>
> *From:*Hoyle, Larry [mailto:larryhoyle at ku.edu]
> *Sent:* Wednesday, February 5, 2020 16:22
> *To:* Wackerow, Joachim; DDI - Structural Reform Group
> *Subject:* RE: [MRT] Open model issues for decision
>
> Classes like Individual inherit from an identifiable super class so 
> they are also identifiable.
>
> Basically there are two kinds of classes. Those that might be 
> referenced and those that are just plumbing and don’t need to be 
> referenced. The latter includes things like position pointers. These 
> are classes because they reference other classes, but one would never 
> reuse them.
>
> *From:*ddi-srg-bounces at icpsr.umich.edu 
> <mailto:ddi-srg-bounces at icpsr.umich.edu> 
> <ddi-srg-bounces at icpsr.umich.edu 
> <mailto:ddi-srg-bounces at icpsr.umich.edu>> *On Behalf Of *Wackerow, Joachim
> *Sent:* Wednesday, February 5, 2020 8:34 AM
> *To:* DDI - Structural Reform Group <ddi-srg at icpsr.umich.edu 
> <mailto:ddi-srg at icpsr.umich.edu>>
> *Subject:* Re: [DDI-SRG] [MRT] Open model issues for decision
>
> Here is an additional list. Attached is a list of all classes and 
> their possible super classes.
>
> The identifiable ones are marked in blue.
>
> The classes without a super class are marked in red.
>
> Achim
>
> *From:*ddi-srg-bounces at icpsr.umich.edu 
> <mailto:ddi-srg-bounces at icpsr.umich.edu> 
> [mailto:ddi-srg-bounces at icpsr.umich.edu] *On Behalf Of *Wackerow, Joachim
> *Sent:* Wednesday, February 5, 2020 13:35
> *To:* DDI - Structural Reform Group
> *Subject:* [DDI-SRG] [MRT] Open model issues for decision
>
> Here is a list of open model issues.
>
> The goal would be that we either find today an agreement or we 
> describe the issue and possible solutions and park the issue.
>
> I’ll then make changes to the model according to the agreed decisions.
>
> 1.Leaf classes without attributes and associations to other classes
>
> a.ControlStep, ScriptingAgent and RulesEngine
>
> i.Jay: they can be removed
>
> b.Sequence and Service
>
> i.Jay: need to remain as is in line with idea that this is a 
> conceptual/logical model that some but not all will use for 
> implementation too (Smile).
> Sequence is a container for other ControlConstructs and because it 
> inherits from ControlLogic which is reflexive maybe Sequence can host 
> other ControlLogic and itself.
> Service is an idea we would like to finish at another time.
>
> c.Designation
>
> i.Ja: Designation is another touchpoint with Signifier, Sign and Signified
>
> ii.Flavio: We are not using Designation anymore
>
> iii.Dan: Designation isn’t really needed since we have the 
> signification pattern. As a result, each application of designation, 
> whether it be a code, term, or other, will be modeled in the 
> realization. Designation, being a generic term, probably is not needed.
>
> d.What is the purpose of UnitSegmentLayout? Does it make sense for 
> future expansion.
>
> 2.PhysicalSegmentLocation has no attributes, only one association to 
> ValueMapping, and only one sub class, SegmentByText. Currently it 
> doesn’t make much sense. Should this be maintained for future expansion?
>
> 3.The current approach of string types seems to be too complicated. 
> The structured string types could be folded into the regular ones. 
> Furthermore, there are some inconsistencies.
> Diagrams on the current approach and the suggested approach are attached.
>
> 4.Missing identifiers for classes in DataDescription, Process, and 
> value? of a Code , see Jay’s email on “new model version 2020-02-04 / 
> generated files” from 2020-02-04.
> Attached is a list of classes in DataDescription and Process. The 
> classes which inherit from Identifable are highlighted.
>
> 5.Identification and Annotation. Identification could be an attribute 
> not a super class (otherwise “, annotation could be a separate class.
> The current model uses Identifiable and AnnotatedIdentifiable as super 
> classes. The Identifable is just “Data-Based Inheritance”. There are 
> currently 16 classes which inherit directly from Identifiable and 23 
> classes which inherit directly from AnnotatedIdentifiable. There are 
> overall 110 classes which inherit from other classes and finally from 
> Identifiable.
> The information which is captured by Identifiable can be modeled as a 
> data type which could be used as attribute with the name “identifier” 
> for each class. Even the information which is captured by 
> AnnotatedIdentifiable can be modeled as a data type. The exception is 
> the association to AgentAssociation. There are four m:n associations 
> from AnnotatedIdentifiable to AgentAssociation, each with some kind of 
> role (publisher, contributor, versioning agent, creator). The weird 
> thing is that AgentAssociation itself has again a role item (external CV).
> I see here some requirement for discussion how this could be 
> simplified. Diagrams on the current approach and one suggested 
> approach are attached.
>
> a.The information of Identifiable and AnnotatedIdentifiable could be 
> collapsed into one structured data type with the exception of 
> AgentAssociation.
> Annotation could be an attribute of Identifier. This would be more 
> limited than the current solution in terms of the annotation relationship.
>
> b.Another approach would be to have associations from classes which 
> need Annotation. One annotation could be then used for many classes. A 
> related super class could be constructed. The latter approach would 
> make distinction between identification (which would be an attribute) 
> and annotation (to which an association would exist).
>
> c.A third approach would be to include the identification information 
> in the super class described in b). This is similar to the current 
> approach but Annotation is not tied to a single class. This seems to 
> be a flexible solution.
>
> Achim
>
>
> _______________________________________________
> DDI-SRG mailing list
> DDI-SRG at icpsr.umich.edu
> http://lists.icpsr.umich.edu/mailman/listinfo/ddi-srg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.icpsr.umich.edu/pipermail/ddi-srg/attachments/20200205/ef0d032a/attachment-0001.html