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

Wed Feb 5 10:02:13 EST 2020

There are tons of XML Unit testing frameworks we can use, it's just that 
we never got that far to need them...

On 2020-02-05 10:00 a.m., Wackerow, Joachim wrote:
>
> Jay,
>
> I think MRT is still very weak on the T.
>
> We would need test cases formalized as XML and/or RDF. Furthermore, 
> the definitions of constraints for these use cases would be important. 
> Then, validation on this secondary level could take place.
>
> Achim
>
> *From:*Jay Greenfield [mailto:nightcleaner at gmail.com]
> *Sent:* Wednesday, February 5, 2020 15:54
> *To:* Wackerow, Joachim
> *Cc:* DDI - Structural Reform Group
> *Subject:* Re: [DDI-SRG] [MRT] Open model issues for decision
>
> Achim:
>
> Does the production system include a test suite so we can ascertain 
> whether model changes first break the usability of the remaining model 
> and then whether model changes actually work as expected?
>
> How do we test a model before it is published?
>
> Jay
>
> On Feb 5, 2020, at 9:33 AM, Wackerow, Joachim 
> <Joachim.Wackerow at gesis.org <mailto:Joachim.Wackerow at gesis.org>> wrote:
>
> 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
>
> <ClassesAndTheirSuperClasses.xlsx>_______________________________________________
> DDI-SRG mailing list
> DDI-SRG at icpsr.umich.edu <mailto:DDI-SRG at icpsr.umich.edu>
> http://lists.icpsr.umich.edu/mailman/listinfo/ddi-srg
>
>
> _______________________________________________
> 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/6443a8ca/attachment-0001.html 