Open philbarker opened 1 year ago
Good analysis, @philbarker. I would add one point. I do not think that transformed
should be a mapping predicate option for two reasons: (1) it does not align with the meaning and purpose of mapping predicates which are to express the level of comparability between the two terms being mapped; and (2) if the mapper selects transformed
, there is no means of also expressing the level of comparability (e.g., picking transformed
and also reworded
). Possibly consider a clearly defined transformed
option as a boolean toggle available to all individual mappings ... perhaps even triggering some mechanism for formally capturing the nature of the transformation (of which I have no immediate thoughts).
Sometimes the entity-relation models of different standards are very different. For example, some standards for Competency Definitions show relationships directly between Competencies with different properties for different types of relationship, in others there is an intermediary object that defines the nature of the relationship. Another example is that in some standards the name-properties for a person (such as: given name, family name, display name) are directly attached to the Person object whereas in others there is a Name entity that can be repeated to provide all those properties for uses such as preferred name, legal name, former name etc. Finally it might be that what in one standard is a single class is represented by many related (sub-)classes in another.
Often the modelling is very different for graph-based and tree-based approaches.
Mapping between different models can difficult, but we could handle it better by
transformed
can very useful in showing when data from different parts of one model needs to be combined in order to map to another, but we should allow the transformations to be represented in a machine actionable notation (the different notations would be suitable for different modelling frameworks / execution environments).