[DDI-SRG] [CDI] new Canonical XMI after model transform
Flavio Rizzolo
flavio.rizzolo at gmail.com
Mon Aug 9 15:15:07 EDT 2021
On a second thought, perhaps it is just better to just get rid of
InformationObject entirely given that making every single class
susceptible of being input/output to a Process an extension of
InformationObject is going to be very messy. We could use a simple
soft-link mechanism, e.g. the facade, to get a similar, less messy result.
Flavio
On 2021-08-06 3:48 p.m., Flavio Rizzolo wrote:
>
> This user/implementation guide is becoming more critical the more we
> review the model. How, and when, to use identifiable is the latest
> addition to the guide, I'd say.
>
> As part of the Process model review, I have a couple of proposals
> related to InformationObject:
>
> - Current definition: "An InformationObject may be a data object or a
> metadata object either used or produced by an Activity. A program that
> creates InformationObjects is also an InformationObject."
>
> - Proposed definition: "Data or Conceptual object playing the role of
> input or output of an Activity." I don't think we want to have
> programs as input/outputs at this point, that would be too "meta" and
> create some confusion.
>
> - Currently, InformationObject is only the parent class of different
> types of Datasets, VariableCollection and EnumerationDomain. No
> individual values, variables or even concepts of any kind. By
> restricting InformationObjecs to those classes, the usability of the
> model in practical scenarios is vastly reduced. I suggest to either
> make every class in Conceptual and DataDescription a subtype of
> InformationEntity, or at the very least add to the existing ones
> Concept and Datum.
>
> - Finally, rename it to "Entity", or "InformationEntity", or something
> similar, more inline with PROV and others. I don't like the use of
> "object" when actually referring to a class in GSIM, and I think we
> could just avoid using it here.
>
> Flavio
>
>
> On 2021-08-06 2:39 p.m., A. G. wrote:
>> Flavio:
>>
>> It has become clear to me as I have looked at a couple of examples
>> that what you say is true.
>>
>> One major topic for the Dagstuhl week will be to design and document
>> a methodology for creating implementation guides. These would
>> describe both the selection of classes to be used from the model, and
>> relevant choices about syntac representation.
>>
>> Without this - functioning basically as a checklist for a community
>> implementing the model, but one which can be shared with others to
>> support interoperability - I do not see a model of this complexity
>> being practically useful.
>>
>> One aspect of this which has become evident is that with a minimum
>> received metadata payload, it is possible to use the model to derive
>> much greater richness within the system processing that metadata,
>> especially if the implementation details are known.
>>
>> The best example of this I have seen so far is an RDF implementation
>> prototype where users are expected to describe their instance
>> variables, and to indicate whether the concept employed and/or the
>> enumerated values are taken from an authoritative source. With this
>> information it is possible to populate the entire variable cascade in
>> a useful way, suitable for a system designed to identify reuse
>> programmatically.
>>
>> I think this kind of hidden complexity is actually very powerful.
>> Although we need responsible users it will help a lot if we can tell
>> them what we mean by "responsible". That burden should be as light as
>> possible for our adopters.
>>
>> Cheers,
>>
>> Arofan
>>
>> On Friday, August 6, 2021, 06:09:04 PM GMT+2, Flavio Rizzolo
>> <flavio.rizzolo at gmail.com> wrote:
>>
>>
>> That would depend on the syntax representation, in XML or JSON you
>> can use the nesting of elements without needing further references...
>> In any case, I lost track of how many times we went back and forth on
>> this, I made the suggestion because I thought we were not identifying
>> everything in this iteration... my bad.
>>
>> The identifier is optional anyways, we could emphasize in the
>> documentation that if the syntax representation of your choice
>> doesn't need it in certain cases, then don't use it. That would
>> create other interoperability problems since some people might drop
>> identifiers even when they are really required, but I don't see any
>> way around that since we are given tons of flexibility to the users,
>> and with great flexibility comes great responsibility...
>>
>> Flavio
>>
>>
>> On 2021-08-06 10:57 a.m., Hoyle, Larry wrote:
>>
>> Unfortunately, anything that is at the navigable end of an
>> association needs an identifier. This does not mean that these need
>> to be heavily (centrally) managed – a random UUID could work for the
>> ddiIdentifier attribute of the Identifier. The Position class is an
>> example. A list needs to be able to refer to the positions of the
>> objects in the list. If these Positions do not have unique
>> identifiers, a saved instance of the list and its associated
>> positions becomes unusable.
>>
>> Since we cannot foresee future uses of existing classes in the model,
>> all classes should have an identifier property. This is how we have
>> been doing this for quite a while now. This is one of the primary
>> distinctions between classes and structured datatypes.
>>
>> Please let’s not get into remodeling this at this late date.
>>
>> Larry
>>
>> *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 *Flavio Rizzolo
>> *Sent:* Friday, August 6, 2021 8:40 AM
>> *To:* ddi-srg at icpsr.umich.edu <mailto:ddi-srg at icpsr.umich.edu>
>> *Subject:* Re: [DDI-SRG] [CDI] new Canonical XMI after model transform
>>
>> Yes, that's a good point Larry. The question is whether that is the
>> case, or it's just safer to remove them from all abstract classes
>> with the idea we'll add them in the concrete classes as necessary.
>>
>> The pattern classes also have identifier, even in the cases in which
>> the concrete classes shouldn't have them, e.g. keys and keymembers. I
>> think the criteria for having identifiers is not only that they will
>> be instantiated but also that the instance can live on its own and is
>> worth referencing, which is not the case of something like keys and
>> keymembers (besides, it would really be an overkill to add
>> identifier, which is not light, to something like a keymember, which
>> is essentially a pointer linking data points).
>>
>> The idea at some point was to use composition to indicate when two
>> classes formed a single whole so that the parts didn't require
>> separate identification from the whole. They keys certainly satisfy
>> that, since the are parts of a dataset. Position in List is another
>> example.
>>
>> Flavio
>>
>> On 2021-08-06 7:56 a.m., Hoyle, Larry wrote:
>>
>> As to the last point:
>>
>> I would think that adding an identifier to an abstract class is
>> done not because I would think that adding an identifier to an
>> abstract class is done not because you expect to identify the
>> abstract class itself, but because you intend that all classes
>> inheriting from it are identifiable. A Flavio pointed out, by
>> being abstract, a class is never intended to be used directly. It
>> only exists to describe what properties and relationships its
>> descendants must have.
>>
>> I would not remove the identifier from an abstract classes
>> without thinking about whether all descendants are intended to be
>> identifiable.
>>
>> *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:* Friday, August 6, 2021 6:42 AM
>> *To:* DDI Structural Reform Working Group.
>> <ddi-srg at icpsr.umich.edu> <mailto:ddi-srg at icpsr.umich.edu>
>> *Subject:* Re: [DDI-SRG] [CDI] new Canonical XMI after model
>> transform
>>
>> Thanks Flavio, for the things you noticed. This is helpful. My
>> comments are below in the message.
>>
>> Keep checking!
>>
>> Achim
>>
>> *From:*Flavio Rizzolo <flavio.rizzolo at gmail.com
>> <mailto:flavio.rizzolo at gmail.com>>
>> *Sent:* Freitag, 6. August 2021 03:39
>> *To:* Wackerow, Joachim <Joachim.Wackerow at gesis.org
>> <mailto:Joachim.Wackerow at gesis.org>>; DDI Structural Reform
>> Working Group. <ddi-srg at icpsr.umich.edu
>> <mailto:ddi-srg at icpsr.umich.edu>>
>> *Subject:* Re: [DDI-SRG] [CDI] new Canonical XMI after model
>> transform
>>
>> A couple of other issues:
>>
>> - The "refine" association seems to have a unique name now, even
>> in the non-unique names xmi. For instance, Concept "refines"
>> IndividualMember. Instead, we have Concept
>> "Concept_refines_IndividualMember" IndividualMember.
>>
>> */[JW] The name should be probably removed in the regular XMI
>> file. The long name should be in the version with the unique
>> association names. The background of the refine names is that
>> some UML tools are not able to consume the abstraction
>> stereotypes. They just ignore them which results in a Abstraction
>> relationship without further specification. Using the name is a
>> workaround. But this is confusing in a tool like EA which can
>> consume the abstraction stereotypes. The name repeats what is
>> already expressed in the specific abstraction relationship.
>> Another workaround would be to describe the kind of relationship
>> in the definition./*
>>
>> */I will remove the names in the regular XMI file. I’ll add the
>> long names to the version with the unique association names./*
>>
>> */You could think about if the abstraction definitions could be
>> improved in a way that the kind of relationship is clear even if
>> an UML tool doesn’t understand the related stereotypes like refine./*
>>
>> - Identifier appears in all classes in the inheritance chains.
>> For instance, Activity has Identifier, and so does Step, which is
>> an extension of Activity. However, only the top non-abstract
>> class in any inheritance chain should have Identifiable.
>>
>> */[JW] I didn’t think about this./*
>>
>> */I will remove the attribute identifier at all classes which
>> inherit from a non-abstract class./*
>>
>> - Which brings me to the next issue: abstract classes should not
>> be identifiable, should they? They are never instantiated, so it
>> seems pointless they hay an identifier.
>>
>> */[JW] Absolutely./*
>>
>> */I’ll remove the attribute identifier from abstract classes./*
>>
>> Flavio
>>
>> On 2021-08-05 2:00 p.m., Flavio Rizzolo wrote:
>>
>> Achim,
>>
>> A few issues I noticed on a quick review:
>>
>> - The definition of Identifier seems old. It says "Basic
>> object requiring identification. Elements of this type are
>> versioned and provide administrative metadata properties."
>> It's a datatype now, so it should probably say "identifier
>> for objects requiring short- or long-lasting referencing and
>> management", or something like that. The example seems wrong
>> as well "Use for First Order Classes whose content does not
>> need to be discoverable in its own right but needs to be
>> related to multiple classes.". I suggest to remove it.
>>
>> */[JW] For the next transformation run, I would need the
>> documentation of both the class attribute identifier and the
>> data type Identifier. It could be the same definition./*
>>
>> */“Identifier for objects requiring short- or long-lasting
>> referencing and management.” seems to be good enough./*
>>
>> */The suggested removal is fine with me./*
>>
>> - Some of the attributes, e.g. ddiIdentifier, uri, appear to
>> be of type "EA_Java_Types_Package". I'm not sure how that
>> happened.
>>
>> */[JW] I typed them as strings. I will look into this. This
>> is an issue with EA and their use of UML primitives and how
>> they express them in their version of XMI./*
>>
>> - There is a ModelIdentification datatype, right under the
>> DataTypes package, that doesn't seem to be used anywhere.
>>
>> */[JW] I added this already to the public review version. It
>> is not used anywhere in the model but it can be used by any
>> program which uses the model or its representations. This way
>> a program can recognize with which specification and version
>> it deals with./*
>>
>> */This could stay on the level of the data types like
>> currently or it could be located just below DDICDILibrary.
>> What do you think?/*
>>
>> - I was just going over the Documentation.xlsx and noticed a
>> couple of enumerations that didn't ring a bell. I checked and
>> couldn't find them in the latest EA file. They are
>> WorkflowPattern and StringStructureType. There might be
>> others. I'm not sure where they are coming from.
>>
>> */[JW] StringStructureType was removed because I simplified
>> all string data types. It is now an external controlled
>> vocabulary. Hard coding would be too limited./*
>>
>> */WorkflowPattern is not used at all. I removed it but missed
>> to document it./*
>>
>> That's all for now. I'll keep checking.
>>
>> Flavio
>>
>> On 2021-07-30 2:59 p.m., Wackerow, Joachim wrote:
>>
>> I did the programmatic model transformation for a couple
>> of issues we talked about. Prior to that I edited
>> manually the EA model regarding some other issues.
>>
>> I documented all changes in
>> ModelTransformation_2021-07-30.docx
>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.dropbox.com%2Fs%2F8fkxs38snd6ss2d%2FModelTransformation_2021-07-30.docx%3Fdl%3D0&data=04%7C01%7Clarryhoyle%40ku.edu%7C90f00183acdc41690ded08d958dfc001%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638541223322476%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fcJpNbWGyBHeqSODTIwCgVHjq%2F9gxon7%2F8lB7pagvBE%3D&reserved=0>.
>>
>> The file lists also some items which need documentation.
>> Volunteers sought.
>>
>> While doing this work I filed a couple of additional issues:
>>
>> 1. Missing documentation *CDI-57*
>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fddi-alliance.atlassian.net%2Fbrowse%2FCDI-57&data=04%7C01%7Clarryhoyle%40ku.edu%7C90f00183acdc41690ded08d958dfc001%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638541223332464%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=faHh4c%2Fj%2FpM5bQFlonDnJjWeiSGNx4BUurxb88vzKAs%3D&reserved=0>
>> 2. Boolean class attributes: should they have a default
>> value? *CDI-56*
>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fddi-alliance.atlassian.net%2Fbrowse%2FCDI-56&data=04%7C01%7Clarryhoyle%40ku.edu%7C90f00183acdc41690ded08d958dfc001%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638541223332464%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ZSjwVi%2BsDyC5HMdMHfDPhzmYpWK6EBbb5Wg7Cc54eFI%3D&reserved=0>
>> 3. Data type ObjectName attributes are not clear.
>> *CDI-55*
>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fddi-alliance.atlassian.net%2Fbrowse%2FCDI-55&data=04%7C01%7Clarryhoyle%40ku.edu%7C90f00183acdc41690ded08d958dfc001%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638541223342460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XYiTITReBO%2BMSZJD%2FspKTP%2FExt%2F3ew%2BBow9tLMUOV84%3D&reserved=0>
>> 4. Data type name "SpecificationType" too generic
>> *CDI-54*
>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fddi-alliance.atlassian.net%2Fbrowse%2FCDI-54&data=04%7C01%7Clarryhoyle%40ku.edu%7C90f00183acdc41690ded08d958dfc001%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638541223342460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=LHIeTvUxcWyv6Q9wqXlST3UiYUJzYWyUOvF3rGThc0M%3D&reserved=0>
>> 5. Review names of enumerations and data types. Several
>> have the suffix 'type'. *CDI-58*
>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fddi-alliance.atlassian.net%2Fbrowse%2FCDI-58&data=04%7C01%7Clarryhoyle%40ku.edu%7C90f00183acdc41690ded08d958dfc001%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638541223352454%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=HiNxBmzdMDp9GI93%2FqMON6HJklaqgT9uEgv86lcuXvE%3D&reserved=0>
>>
>> The new files include everything below DDICDIModels. The
>> abstraction stereotypes like trace are maintained.
>> Diagrams get lost in this process.
>>
>> The new XMI files (DDI-CDI_2021-07-30.xmi
>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.dropbox.com%2Fs%2Foizidnadhqeo1s7%2FDDI-CDI_2021-07-30.xmi%3Fdl%3D0&data=04%7C01%7Clarryhoyle%40ku.edu%7C90f00183acdc41690ded08d958dfc001%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638541223352454%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=leUhBgg258UiamqdktvsK15NTstsvv0gLaVAS%2BPg6eY%3D&reserved=0>,
>> DDI-CDI_UniqueAssociationNames_2021-07-30.xmi
>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.dropbox.com%2Fs%2Fsv3h4cof4i499xx%2FDDI-CDI_UniqueAssociationNames_2021-07-30.xmi%3Fdl%3D0&data=04%7C01%7Clarryhoyle%40ku.edu%7C90f00183acdc41690ded08d958dfc001%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638541223362451%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=nUIHHZaIxk5f46RCQbjOJ5wI6hRnhFvWqx8zpFJiaSg%3D&reserved=0>)
>> are available for download.
>>
>> Please review. There might be issues.
>>
>> Achim
>>
>> _______________________________________________
>>
>> 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
>> <https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.icpsr.umich.edu%2Fmailman%2Flistinfo%2Fddi-srg&data=04%7C01%7Clarryhoyle%40ku.edu%7C90f00183acdc41690ded08d958dfc001%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638541223372444%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CHEvcw%2BTHHfyBNDnOsWB%2BOe%2FQTi9fqQclyJ%2FB4oUXE8%3D&reserved=0>
>>
>>
>>
>> _______________________________________________
>>
>> 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 <https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.icpsr.umich.edu%2Fmailman%2Flistinfo%2Fddi-srg&data=04%7C01%7Clarryhoyle%40ku.edu%7C90f00183acdc41690ded08d958dfc001%7C3c176536afe643f5b96636feabbe3c1a%7C0%7C0%7C637638541223372444%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CHEvcw%2BTHHfyBNDnOsWB%2BOe%2FQTi9fqQclyJ%2FB4oUXE8%3D&reserved=0>
>>
>> _______________________________________________
>> 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
>> <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/20210809/c6c7698e/attachment-0001.html
More information about the DDI-SRG
mailing list