Difference between revisions of "06.09.2013 VME"

From D4Science Wiki
Jump to: navigation, search
 
Line 3: Line 3:
 
'''Date''': 06-09-2013 11:10 – 12:15
 
'''Date''': 06-09-2013 11:10 – 12:15
  
 +
'''Participants''': E. van Ingen, M.Assante, A.Ellenbroek (50%)
  
 
'''Topics''':  
 
'''Topics''':  
−
Massi explained the iMarine Reports and I have explained a bit more the KeyValue Editor and VME in general. It was very helpful for me to discuss with Massi in order to be able to describe better the problem. This is my outcome of the discussion:
+
Massi explained the iMarine Reports and Erik explained the KeyValue Editor and VME in general.  
  
−
The VME object graph http://km.fao.org/FIGISwiki/index.php/Image:VmeDomain.jpg has  various breakdowns. For instance Rfmo-Vme-SpecificMeasures. Or Vme-Profile, etc. The VME object graph is reflected in the VME Oracle DB. If necessary, the VME object graph could also be considered as a tree.
+
It was very helpful in order to be able to describe better the problem. This is my outcome of the discussion:
  
−
It is important to understand that the VME factsheets (including URI's) are generated out of this VME DB. While generating, a lot of information is multiplied, for instance the Rfmo and the GeneralMeasures. Therefore a fine grained solution is needed. Furthermore, the VME DB is in the FAO premises, which requires iMarine to be more or less stateless towards the VME-DB.  
+
* The VME object graph http://km.fao.org/FIGISwiki/index.php/Image:VmeDomain.jpg has  various breakdowns. For instance Rfmo-Vme-SpecificMeasures. Or Vme-Profile, etc. The VME object graph is reflected in the VME Oracle DB. If necessary, the VME object graph could also be considered as a tree.  
  
−
iMarine Reports does consider only one level, the report. Next, there is a collection of reports. This course grained paradigm cannot be applied to a relatively fine grained model like VME. There is data editing and workflow on different levels, Rfmo, Vme, Measuseres etc. This coarse grained paradigm can be applied to factsheets, like for instance the FishFinder.  
+
* It is important to understand that the VME factsheets (including URI's) are generated out of this VME DB. While generating, a lot of information is multiplied, for instance the Rfmo and the GeneralMeasures. Therefore a fine grained solution is needed. Furthermore, the VME DB is in the FAO premises, which requires iMarine to be more or less stateless towards the VME-DB.  
  
−
Roughly there are these options:
+
* iMarine Reports does consider only one level, the report. Next, there is a collection of reports. This course grained paradigm cannot be applied to a relatively fine grained model like VME. There is data editing and workflow on different levels, Rfmo, Vme, Measures etc. This coarse grained paradigm can be applied to factsheets, like for instance the FishFinder.  
−
• Extending iMarine Reports with stateless more fine grained functionality (managed diff in iMarine, state of the DB outside iMarine)
+
−
• Conclude that iMarine Reports should not be abused/positioned for manipulating an object graph with multiple levels and cardinalities and advise the VME project to develop a custom solution.  
+
  
−
The first option foresees a generated GUI through predefined templates. Will a generated GUI be user friendly enough in order to offer to the RFMOs (question raised also by Fabio)? Will this in the future also allow CMS-like functions like preview and restore?
+
* Roughly there are these options:
 +
** Extending iMarine Reports with stateless more fine grained functionality (managed diff in iMarine, state of the DB outside iMarine)  
 +
** Conclude that iMarine Reports should not be abused/positioned for manipulating an object graph with multiple levels and cardinalities and advise the VME project to develop a custom solution.
  
−
The VME project needs a decision as soon as possible. I believe by the end of November, the VME project needs a solution. Please comment on the above email. We will setup a Skype meeting to discuss further.
+
* The first option foresees a generated GUI through predefined templates. Will a generated GUI be user friendly enough in order to offer to the RFMOs (question raised also by Fabio)? Will this in the future also allow CMS-like functions like preview and restore?
−
 
+
−
 
+
−
'''Participants''': E. van Ingen, M.Assante, A.Ellenbroek (50%)
+
  
−
'''Notes'''
+
* The VME project needs a decision soon; by the end of November, the VME project needs a solution.
  
−
* FAO is looking for a solution to EDIT VME reports.  
+
* We will setup a Skype meeting to discuss further.
−
* These reports are not singular objects, rather combine data from a fine grained model.
+
−
* FAO proposed a model described here ...., which would be accessible through a web-service described here ...
+
−
* Web-services would offer the following functionality:
+
−
** Identify a report in need of editing in the FAO infra
+
−
** Download this report into the iMarine WF and reporting Tool.
+
−
** Upload the diff after completion in the report editor
+
−
** Forward the diff to the FAO infra
+
−
* iMarine would thus offer a service for maintaining FAO fact sheets
+

Latest revision as of 15:29, 6 September 2013

Meeting Notes: call on Biodiv (web conferencing)

Date: 06-09-2013 11:10 – 12:15

Participants: E. van Ingen, M.Assante, A.Ellenbroek (50%)

Topics: Massi explained the iMarine Reports and Erik explained the KeyValue Editor and VME in general.

It was very helpful in order to be able to describe better the problem. This is my outcome of the discussion:

  • The VME object graph http://km.fao.org/FIGISwiki/index.php/Image:VmeDomain.jpg has various breakdowns. For instance Rfmo-Vme-SpecificMeasures. Or Vme-Profile, etc. The VME object graph is reflected in the VME Oracle DB. If necessary, the VME object graph could also be considered as a tree.
  • It is important to understand that the VME factsheets (including URI's) are generated out of this VME DB. While generating, a lot of information is multiplied, for instance the Rfmo and the GeneralMeasures. Therefore a fine grained solution is needed. Furthermore, the VME DB is in the FAO premises, which requires iMarine to be more or less stateless towards the VME-DB.
  • iMarine Reports does consider only one level, the report. Next, there is a collection of reports. This course grained paradigm cannot be applied to a relatively fine grained model like VME. There is data editing and workflow on different levels, Rfmo, Vme, Measures etc. This coarse grained paradigm can be applied to factsheets, like for instance the FishFinder.
  • Roughly there are these options:
    • Extending iMarine Reports with stateless more fine grained functionality (managed diff in iMarine, state of the DB outside iMarine)
    • Conclude that iMarine Reports should not be abused/positioned for manipulating an object graph with multiple levels and cardinalities and advise the VME project to develop a custom solution.
  • The first option foresees a generated GUI through predefined templates. Will a generated GUI be user friendly enough in order to offer to the RFMOs (question raised also by Fabio)? Will this in the future also allow CMS-like functions like preview and restore?
  • The VME project needs a decision soon; by the end of November, the VME project needs a solution.
  • We will setup a Skype meeting to discuss further.
Retrieved from "https://wiki.d4science.org/index.php?title=06.09.2013_VME&oldid=15050"