output problems

[fvilla]

2) for some strange reason, model -d core.models.sediment-puget/source-puget core.contexts.beta/wria9_1024 produces valid-looking star diagrams, yet when I model -o source-puget, only the slope-stability and percent-vegetation-cover input layers have any data in them. Can you run and see if it's possible to replicate that?

[fvilla]

Those depend on VegetationType and SlopeClass not ranking properly. VegetationType is an OrdinalRangeMapping, through habitat:EcosystemQuality which is also reported to be subclassed from it. This is ridiculous, particularly because I can't find where that happens in the ontologies. Must be a protege turd somewhere, but so far no luck finding it.

The ranking attribution algorithm sees that and tries to classify the subclasses, failing, so no mappings class->number are generated and all concepts classify to 0. Now I wasted my whole Sat morning to find this, so now I really have to do something else. Will try to understand or circumvent this BS on Monday. If extremely urgent, the concepts that don't show in the .nc files should reappear by adding a thinklab.ordering property in config for their subclasses.

[kbagstad]

Well, I've tried to fix this problem, (wrongly) recreating local VegetationType concepts in the soilretentionEcology.owl file. I still fail to understand how the ranking can work for all other BNs and fail so spectacularly on sediment source, but then again there's very little that I understand these days...

[fvilla]

It must be some major mess in the ontologies - an obvious place for problems given how long they've been around and how many iterations they went through. I couldn't find it myself. But for the sake of sanity, I suggest that you decide the ordering you want and add the corresponding thinklab.ordering... property in the colormaps.config file, which will take over any other reasoning in thinklab. That should quickly fix all those cases where you get data but they don't show up in netcdf - as said, netcdf can only show numbers so that "unclassification" step is necessary. If the first concept in the ordering is a "no" or "absent", the numbers will start at 0, otherwise at 1, and they will follow the order you mentioned. We will fix the ontologies when we get to them, which should be a major restructuring when things are calmer.

[lambdatronic]

Added thinklab.ordering entries for all dependent concepts of core.models.sediment-puget/source-puget to aries.core/config/colormaps.properties.

[lambdatronic]

@kbagstad @fvilla Is this resolved, or is the problem still there?