[BUG]: Successful evaluation of property relations to a single-valued property dependent on ordering of multi-valued properties in source

[ejn]

Describe the bug
When evaluating a property relation (here specifically Regex Analysis) on a multi-valued property (here XSD 0..n), with a the target being a single-valued property (here XSD 0..1), the evaluation appears to only be performed against the first source value.

To Reproduce
The attachment aaa-tn-ln-sample.zip contains an alignment with a single type relation Retype between AX_FlaecheGemischterNutzung and LN_Forstwirtschaft. This contains two Regex Analysis property mappings from zeigtAufExternes/AA_Fachdatenverbindung/fachdatenobjekt/AA_Fachdatenobjekt/name to art, whereby zeigtAufExternes has cardinality 0..n and art cardinality 0..1. The aim of these mappings is that if the source object contains an AA_Fachdatenverbindung with a particular value then an appropriate value may be assigned to art - i.e. a classification performed on substring matches of the source value.

This alignment was used to transform the GML contained in source.zip. This contains two AX_FlaecheGemischterNutzung features, both of which have two zeigtAufExternes/AA_Fachdatenverbindung. In the first object (DEMVAL0300bebrte) the relevant AA_Fachdatenverbindung is the first of these, in the second object (DEMVAL7600fucDbr) the second.

The result of this transformation is in transformed.zip: Here it can be seen that the feature derived from DEMVAL0300bebrte has art set to 6200 from the Regex Analysis mapping, whereas DEMVN17600fucDbr has no art set, despite also having a matching AA_Fachdatenverbindung.

source-fdv-reversed.zip contains exactly the same two features, but in each case the order of AA_Fachdatenverbindung are reversed compared to the previous example. As can be seen in the result of the transformation transformed-fdv-reversed.zip the resulting art properties are also reversed - the feature derived from DEMVN17600fucDbr now has art set to 6200 whereas the feature derived from DEMVAL0300bebrte has no art set.

Expected behavior
The ordering of the property values in the source should only be relevant in the case that multiple possible values for the target result from the transformation: Here it would be expected/acceptable that (in respect to any priorities defined for the individual property relations if more than one is present for a given target property), the resulting value is derived from the first matching property value in the source. In the case that the evaluation of the source property values only results in a single target property value then the order of the source property values should be irrelevant.

In other words, in the current case the Regex Analysis should be tested against all source property values present within the source feature until either a match is found (with resulting derived value assigned to the target property) or all source property values have been tested: Currently it appears that only the first source property value is evaluated.

Additional context
Note that if an index context is used then it would of course be correct to evaluate against only a single source value - that is however not the case in this example, and since the ordering of the source property values is arbitrary then an index context would be inappropriate.

[stempler]

When evaluating a property relation (here specifically Regex Analysis) on a multi-valued property (here XSD 0..n), with a the target being a single-valued property (here XSD 0..1), the evaluation appears to only be performed against the first source value.

Yes, that's the current behavior in general. If during the creation of the transformation graph in the target no possibility is found to map the multiple occurrences to, only the first instance is transformed. There should be a related warning message.

Right now you could achieve something like you want with a so called "greedy" function. A "greedy" function receives all source occurrences and needs to process them. For your use case you could use the Groovy script function (make it greed in the function options) and check all source values.

A condition context on the source field could also help, if the condition you desire can be expressed in CQL/ECQL. Then you could map the source field with the associated condition.

[ejn]

I find that the related warning message DuplicationContext present, but no matching target found. (4 times) is not exactly easy to interpret!

I tried the idea of using a condition context on the source property, but this does not appear to work. I tried applying the condition much as it is defined on the source type to either zeigtAufExternes (e.g. ("AA_Fachdatenverbindung.art" = 'urn:adv:fdv:2610') AND ("AA_Fachdatenverbindung.fachdatenobjekt.AA_Fachdatenobjekt.name" LIKE '______ LN_Forstwirtschaft ART6200 %')) or to AA_Fachdatenverbindung (e.g. ("art" = 'urn:adv:fdv:2610') AND ("fachdatenobjekt.AA_Fachdatenobjekt.name" LIKE '______ LN_Forstwirtschaft ART6200 %')), but neither of these in combination with an Assign (Bound) on the AA_Fachdatenobjekt.name of the resulting context element produced an art property on the target. The latter of these attempts is in attachment aaa-tn-ln-sample-property-condition-context.zip

So it looks like currently the only way to reliably accomplish this mapping is with a Groovy function, or by duplicating the whole mapping with modified condition contexts at the feature level for each required value.

[stempler]

but neither of these in combination with an Assign (Bound) on the AA_Fachdatenobjekt.name of the resulting context element produced an art property on the target.

Is the issue that the condition somehow does not match or something else? The first can be for example checked with the "Occurring values" in the Properties view when the source element with the condition is selected. Prerequisite is obviously that you have data loaded where the condition is met.

[ejn]

The condition somehow does not match. Even reducing the condition right down to just the art on the AA_Fachdatenverbindung or AA_Fachdatenverbindung.art on zeigtAufExternes results in no matches being shown.

This attachment contains the test alignment, with separate Assign (Bound) on both zeigtAufExternes ("AA_Fachdatenverbindung.art" = 'urn:adv:fdv:2610') and AA_Fachdatenverbindung ("art" = 'urn:adv:fdv:2610'). Neither shows any instances in the source (and therefore no result in the target) using the source.zip. Removing the condition contexts on the properties results in hits, so I therefore assume there is some problem in evaluating the condition contexts.

[stempler]

Not sure what you are trying to accomplish exactly. I created an example how this could work in the project:

1. Condition context on zeigtAufExternes.AA_Fachdatenverbindung selecting only a specific art
2. The UI shows that there are two instances of zeigtAufExternes.AA_Fachdatenverbindung with that condition (totally there are 4)
3. Map the name within the property with the condition to description in the target
4. Note: Since in this case there are two instances in the source there is still the warning (did not find an example quickly where there is only one)

Maybe that helps if you want to do something similar.

test.zip

[ejn]

That's more or less the direction I was trying - but I was missing the value.-prefix from "art" in the context. It also seems to suffer the same problem as previously noted: the Assign (Bound) only works for the feature where the relevant zeigtAufExternes/AA_Fachdatenverbindung is the first one (I assume only the first zeigtAufExternes is considered and then the contained AA_Fachdatenverbindung evaluated rather than evaluating all zeigtAufExternes/AA_Fachdatenverbindung and evaluating the condition until the first match is found, which comes back to the initial problem).

However this leads to a solution which does appear to work: Creating a condition context zeigtAufExternes (("value.AA_Fachdatenverbindung.art" = 'urn:adv:fdv:2610') AND ("value.AA_Fachdatenverbindung.fachdatenobjekt.AA_Fachdatenobjekt.name" LIKE '______ LN_Forstwirtschaft ART6200 %')) and then mapping an Assign (Bound) from the name results in the desired result. A second condition context can then be used for ART6300 to generate the target value for this case.

So thank you for your assistance in finding a solution which works here, but please also consider improving the evaluation of mappings for multiple -> single properties!

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in two weeks if no further activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically closed due to inactivity. If it is still valid, please post a comment.