Issue #81: Error in GSIM & CSPA LIM files - Identifiable Artefact

Meeting 4/4: We need to make a decision on a consistent approach to this. Check with a UML expert to be sure. Alistair Hamilton Eva Holm Francine Kalonji 

I subsequently found out that Identifiable Artefact in the top right of diagrams occurs when you use and show tags where the tag appended manually is Identifiable Artefact.

A tag works visuallly, but I would have preferred a UML figure that shows all information objects that are Identifiable Artefacts.

Hi Jenny, For some reason I remember that we had some conversation when doing the current version of GSIM about the fact that all objects in GSIM can be identifiable. I had the feeling that is why the relationship were not added. But I dont know if I am remembering correctly!

My own confusion arose from Using LIM v0.95 Figure 3 where it was explicitly stated that Process Input is not an Identfiable Artefact.

The question then was, what is and what is not an Identifiable Artefact? Process Output?

If everyone agrees that Process Input IS an Identifiable Artefact, then I am happy to drop my questions on this topic and the Identifiable Artefact tag from the EA files.

This might be a question of asking Eva Holm to see if she can remember back to the Paris 2015 LIM sprint as to why the note is there!

The items directly associated with Identifiable Artefact currently are not saying they are Identifiable Artefacts but that they can be associated with (any) Identifiable Artefact in a particular way.

We have similar constructs that can apply to any "Identifiable Artefact" in the ABS AIM model.  This is useful where a relationship is not between two specific classes but a case of "Class "X" can have a relationship of type "Y" with any Class in the model" (including, technically, itself).

We do, however, also have every class traceable back to our equivalent of "Identifiable Artefact" via inheritance.  Two steps down the tree this leads to

Which is fine.

It may be worth making the inheritance explicit in the next UML version of GSIM if you expect agencies to apply the UML systematically rather than just "know" everything is an Identifiable Artefact?

As Justin will cover in his presentation to the Modernstats Workshop, one of the reasons for the ABS Parameter Set class is to make our operationalised equivalent of ProcessInput and ProcessOutput identifiable, so Jenny's suggestion of doing the equivalent in GSIM may be all you need.

hmmm...note in LIM document says: 

Note: Note: All identifiable objects inherit all attributes from Identifiable Artefact in LIM so these are not explicitly mentioned hereafter. In GSIM v1.1 the Value Type of Name and Description attributes is often Text with cardinality 0…1, but in LIM these attributes are MultilingualText with cardinality 1..1.

What is the cardinality now that we are merging??

I don't see an issue with picking up MultilingualText from LIM, but I'd raise a consideration about the cardinality.

As per the diagram I posted above, most classes in AIM must have names, but not all.  There are some things you may wish to be able to identify and register but not formally name.  These tend to be more technical classes that are useful to have registered to aid in connecting things.

For example, we have a class Structure Use By Program that records information about the use of a Data Structure by a Statistical Program.  (The "use" relationship between DS and SP can be many to many.)  This is a pragmatic thing, we don't want to version Statistical Program or Data Structure when a new "use" occurs, but we do want to be able to quickly trace usage in the registry.  While a name could be made up on an arbitrary basis for the registered example of use, it would be arbitrary, we just want to know the use exists. 

The above example is at a logical level below GSIM but we also see, eg, differentiation between IdentifiableArtefact and NameableArtefact in SDMX.

To some degree the ABS approach to date has leaned toward insisting on Names and Descriptions for classes where such information is meaningful and adds value.  That way our standards area can set guidelines for naming objects associated with the class and discourage "arbitrary junk" names being assigned.

In this sense the current GSIM cardinality is more flexible for national implementations. 

An important point for the GSIM implementation doco to make would be that where GSIM says something is optional there is nothing preventing a national implementation insisting on it in their implementation.  (That can have issues for interoperability, but if making something mandatory would result in "arbitrary junk" being inserted in the field then "arbitrary junk" can be injected during an exchange process to ensure interoperability )

I am not sure if GSIM would consider going down the same path as SDMX (and AIM) and having two (or more) levels of inheritable classes where most (or all) current GSIM classes inherit from (eg) NameableArtefact but national implementations could extend from either IdentifiableArtefact or NameableArtefact as appropriate for the class they need to add for their implementation?

"There are some things you may wish to be able to identify and register but not formally name.  These tend to be more technical classes that are useful to have registered to aid in connecting things". This does rather point out that the intention of GSIM was to have meaningful names for the business, but LIM would cover more technical/logical/structural needs eg introducing a class to cover a many-to-many relationship. Introducing the possibility that some information objects are identifiable and some are not, some are named and some are not, does introduce a level of complexity for the business that might have been better to keep in a logical level, but I guess that train has already left the station. Putting them at a purely physical/implementation level would of course undermine the possibilities for interopreabilty through CSPA that we are hoping for.

ModernStats World discussion 12/4: 

re attributes: Name should be 1..1 and description 0..1. 

re identifiable artefacts - all objects are identifiable. Process input is an object that groups all the identifiable inputs into a process. It is not clear whether this object really needs to be identifiable.

Is it clear whether Process Output really needs to be identifiable? We seem to be going in circles here ...