Domain model needs an AbstractClassSet entity as container for a set of mappings

[stuartasutton]

@jbaird123, @richard0000 & @philbarker, & @jeannekitchens :

We are missing an entity in the DESM domain model. We need to add one class and one new property on desm:AbstractClassMapping (desm:inClassSet). I do not believe this affects anything we have done so far since the new entity simply identifies a set of abstract classes that the creators consider a group. For example, the last "set" of mappings done by the mapping team is presented in the desmAbstractClasses.json SKOS file. That team considers this a grouping. I realize that this is an addition to the current tasks; but, I'd like to get a sense of the level of effort to add this capability to group mappings into a named set.

Figure 1 below is our current domain model. It represents the properties and classes needed to represent the mapping of 1-n schemas to a specific abstract class--e.g., "Competency" or Credential" etc.). There is no means of defining a set of these individual abstract class mappings. Fig. 1: Currrent Domain Model

Figure 2 below solves the problem of grouping together a logically related set of mappings to different abstract classes by adding the classdesm:AbstractClassSet (in red) to the model and referencing it with desm:inClassSet from desm:AbstractClassMapping. Two properties on desm:AbstractClassSet then point to the skos:ConceptScheme--desm:abstractClassModeledType and desm:mapping PredicateType.

Fig. 2: Updated Domain Model

[richard0000]

@stuartasutton in order to correctly estimate this, I will need to determine all the changes this will imply.

E.g. a. Having an initial list of AbstractClassSet's. b. Allowing admin users to create/remove/update/delete AbstractClassSet's with its corresponding attributes. c. Do not let users create a mapping if an AbstractClassSet is not specified. d. Use the name (and optionally some other attributes?) to show somewhere in the process of mapping? e. Anything else...

Apart from that, I don't understand completely the relations desm:abstractClassModeledType and desm:mapping PredicateType.

[stuartasutton]

a. Having an initial list of AbstractClassSet's.

Currently, there is only one instance of AbstractClassSet and that entails the 8 abstract classes we are currently working with. in the tool. The AbstractClassMapping instance for each of those abstract classes point to an instance of AbstractClassSet with the inClassSet property.

c. Do not let users create a mapping if an AbstractClassSet is not specified.

No, there wouldn't necessarily be any AbstractClassSet for a mapping. For example, if you had a SKOS file embodying an instance of AbstractClassType that had only one abstract class, then there would be no need for a set. The AbstractClassSet is only needed in the JSON-LD output of the tool if it had 2 or more 3 frameworks that downstream systems need to treat as a set. This is because outside of the tool, the JSON-LD output has no current means of tying together as a set any number of crosswalks. Therefore, the need for an AbstractClassSet is dependent on whether there is more than one abstract class in the AbstractClassType SKOS file being used.

d. Use the name (and optionally some other attributes?) to show somewhere in the process of mapping?

It doesn't require any new data and need not be displayed anywhere in the tool--just in the output.

Apart from that, I don't understand completely the relations desm:abstractClassModeledType and desm:mapping PredicateType

The AbstractClassSet needs properties to point to the AbstractClassType class and the Mapping PredicateType class so the set has all the information for a mapping profile..

[jbaird123]

Resolved with new config profile dashboard.