search

ariesteam / aries

http://www.ariesonline.org
GNU General Public License v3.0
6 stars 1 forks source link

remaining storyline issues #17

Closed kbagstad closed 12 years ago

kbagstad commented 12 years ago

Remaining questions/issues for you - once these are done I think we'll be able to call the storylines finished:

1) coastal protection storyline: still missing atmospheric pressure & bathymetry concepts in the storyline, and economic value & lives at risk are repeated (& commented out). Since you wrote this storyline, I'm not sure why that's the case or if it should be fixed. 2) carbon.xml has a "fixme" note to yourself 3) aesthetic_prox.xml & aesthetic_view.xml: does the aries:AestheticValueAnalysis concept need to be split into proximity & viewshed? I made this change (created new subclasses for AestheticValueAnalysis - one each for proximity and viewsheds - and updated the storylines - hope that's correct. 4) it would be worth your giving a quick look at the tags that Brian and Gary developed for the flood & sediment storylines - I was never clear on these, and it would be good to be certain that the concepts here are good. 5) note that there are two other questions for you in the sediment assessment files - related to naming the "levees" concept in the ontologies and also to units for sediment erosion and deposition, which are not uniform between the case studies. 6) the top level concept in the water supply storylines is now waterSupplyService:SurfaceWaterMovement. Yet if you look at the water_san_pedro.clj file you'll see that SurfaceWaterMovement applies to both wet and dry year flow models. Is this OK or do those defmodel statements need to reference different ontologic concepts (and if so, then what should the top level concept in the water supply storyline be?) 7) there's some weirdness with one of the concepts in the flood storylines (vegetation type) which is defined differently in the California and Puget sound models - check the comment in the storyline files for flood for more info so I can resolve this.

  1. for some reason in the ARIES explorer 2 versions of the "water supply" storyline are showing up. Not sure why this would be the case, but clearly there should only be one.
kbagstad commented 12 years ago

@fvilla

kbagstad commented 12 years ago

Question 7 from the above list has been resolved per our call with Brian on monday. I'm making major updates to the storylines and will commit changes at the end of the day today. Resolving the other 7 questions above remains a prerequisite to finishing storyline testing.

fvilla commented 12 years ago

1) coastal protection storyline: still missing atmospheric pressure & bathymetry concepts in the storyline, and economic value & lives at risk are repeated (& commented out). Since you wrote this storyline, I'm not sure why that's the case or if it should be fixed.

At the time I was adding stuff manually; these looked awful and I thought they were too much information as the role of both was explained in the text elsewhere. I don't see compelling reasons to add them but I can do so if you prefer.

2) carbon.xml has a "fixme" note to yourself

Yup, that stays there as a reminder - the point is that a storyline should be "about" one of the MA services (or something comparable) instead of a particular analysis, but our ontologies about basic ES classes are unfinished. Same holds for most storylines, and this doesn't change the interface a bit, so I wouldn't worry until we refactor models and ontologies for 2.0.

The carbon assessment storyline needs love - see separate issue on that.

3) aesthetic_prox.xml & aesthetic_view.xml: does the aries:AestheticValueAnalysis concept need to be split into proximity & viewshed? I made this change (created new subclasses for AestheticValueAnalysis - one each for proximity and viewsheds - and updated the storylines - hope that's correct.

Yes, good job. Not entirely necessary as duplicate concepts are allowed (e.g. dry/wet water supply) but these are obviously more specific and more correct.

4) it would be worth your giving a quick look at the tags that Brian and Gary developed for the flood & sediment storylines - I was never clear on these, and it would be good to be certain that the concepts here are good.

Not sure what I should be looking at there - what I see looks good to me. If it's a matter of conceptualizing the main storyline subject, no big deal (see other responses). The 100/500 year thing should obviously be a scenario option and not separate models, but it's my problem to enable this.

5) note that there are two other questions for you in the sediment assessment files - related to naming the "levees" concept in the ontologies and also to units for sediment erosion and deposition, which are not uniform between the case studies.

YES - all concepts should obviously be in the result set in order for the info pages to be useful. If LeveesClass is not there and Levees is, that needs to be Levees. If both MAY be there in different models, BOTH pages are needed - which they shouldn't, see answer to (7).

Note that this XXXClass pattern is also making some mess in the carbon assessment storyline (which basically shows no useful results due to XXXClass concept being documented as XXX only and possibly some concepts missing) and probably elsewhere. See separate issue on that.

6) the top level concept in the water supply storylines is now waterSupplyService:SurfaceWaterMovement. Yet if you look at the water_san_pedro.clj file you'll see that SurfaceWaterMovement applies to both wet and dry year flow models. Is this OK or do those defmodel statements need to reference different ontologic concepts (and if so, then what should the top level concept in the water supply storyline be?)

It's fine, that concept clarifies what the storyline is about - which as said above, should probably be one of the MA services instead of the water movement. Since in this implementation storylines are just taken from the files and shown when they're covered, and don't get chosen using the reasoner based on a model you run, that does no harm. It would become important if we wanted models to pick their own storyline for visualization, but that would require more synchronization than we have now - a good point for future versions, when we have an easier and common language for models, storylines and ontologies. No harm with the duplication either - it's fine to have alternative storylines for the same subject, although if they're different it is good to differentiate. Wet/dry seems more like a scenario issue (which should be a parameter in a single model instead of two models) so I wouldn't change this.

7) there's some weirdness with one of the concepts in the flood storylines (vegetation type) which is defined differently in the California and Puget sound models - check the comment in the storyline files for flood for more info so I can resolve this.

Hm, good point - what this should be is a multiple concept tag for a concept page to document more than one concept - which at the moment isn't implemented or easy to implement. So what you did is right if wasteful. I don't think I'll fix this before the next release (say Spring) so if it's not too much work, please do the same where is needed. If it's too much work let me know and I'll put the fix on the priority list.

fvilla commented 12 years ago

If no action is needed on (4), I am fine with everything here, please close issue if you deem it solved.

kbagstad commented 12 years ago

I'm going to keep this open for a week until I'm back in the office next Thurs to get going in earnest on this. But thanks for the responses, in all likelihood I should be able to wrap it up with a solid day or two of storyline editing.

Ken

On Wed, Dec 7, 2011 at 10:06 AM, Ferdinando Villa reply@reply.github.com wrote:

If no action is needed on (4), I am fine with everything here, please close issue if you deem it solved.

Reply to this email directly or view it on GitHub: https://github.com/ariesteam/aries/issues/17#issuecomment-3047455

kbagstad commented 12 years ago

OK, at long last have my flow concepts refactoring done and am going to make these fixes early next week for good. Two points of clarification:

1) Re: point 1 in my original issue - I thought all input and output data should be included in a storyline, right? What would the point be of not including one or more concepts, provided that the data were redistributable? 2) You're saying that the tags should be MA ecosystem services, right? They are not MA services consistently, so I can do some minor refactoring there if it moves us forward. 3) I'll fix the messes with not including "Class" in the name, etc. next week - no problem there.

kbagstad commented 12 years ago

Uggh. Trying hard to finish the storylines. Deeply, deeply frustrated with their inconsistencies and with not understanding how they fit together. A screensharing session would be hugely beneficial in wrapping this up and reducing my frustration - please let me know if this is possible.

kbagstad commented 12 years ago

OK, the second of the 3 issues in my comment from 12/23 is addressed: top-level storyline tags are now consistent, if most certainly wrong. This puts my mind at ease a little bit but should really be resolved via a short screen-sharing session. On to issues 1 & 3 from 12/23.

kbagstad commented 12 years ago

Moving along: On the coastal protection storyline, I've added atmospheric pressure & bathymetry classes. If they look bad we can always comment them out but at least have them in the storyline.

Question though: Why did you initially put in both LivesAtRiskStorm/CycloneDependentLivesAtRisk and the corresponding pair of assets at risk concepts in the storyline? These seem highly redundant, like one should be removed. Agree?

kbagstad commented 12 years ago

Closing for now and will write a new issue with outstanding storyline issues.