Difference between revisions of "Ecosystem Approach Community of Practice: VME iMarine"
(→Introduction) |
(→Introduction) |
||
| Line 6: | Line 6: | ||
| − | This page talks about key-values as the solution to transfer data from iMarine into the VME-DB. The naked truth is that is composite-key-value solution. The composite key is composed of the type of the object (KeyType), the id of the object(id) and the name of the attribute that is to be manipulated. A composite-key-value solution makes it easier on both sides to manage the data and works particularly well to manipulate an object graph like the VME-DB. | + | This page talks about key-values as the solution to transfer data from iMarine into the VME-DB. The naked truth is that it is composite-key-value solution. The composite key is composed of the type of the object (KeyType), the id of the object(id) and the name of the attribute that is to be manipulated. A composite-key-value solution makes it easier on both sides to manage the data and works particularly well to manipulate an object graph like the VME-DB. |
<br> | <br> | ||
<br> | <br> | ||
Revision as of 10:02, 21 August 2013
Introduction
The VME project has started to investigate how the iMarine infrastructure could work in combination with the VME-DB on FAO side. This page tries to make all assumptions explicit and therefore will probably be heavily used for discussion!
You can find the object graph for the VME-DB here, in order to have an idea of the VME domain model (ask Erik or Anton for the name/password).
This page talks about key-values as the solution to transfer data from iMarine into the VME-DB. The naked truth is that it is composite-key-value solution. The composite key is composed of the type of the object (KeyType), the id of the object(id) and the name of the attribute that is to be manipulated. A composite-key-value solution makes it easier on both sides to manage the data and works particularly well to manipulate an object graph like the VME-DB.
The big picture
UML
TemplateEditor
The VME-DB is an object graph. Every object in the VME-DB is represented in iMarine through a KeyType. Of course an object has attributes, therefore also a KeyType has attributes.
Examples of KeyTypes are Vme, Rfmo, GeneralMeasures, SpecificMeasures, etc.
- Template: Holds a collection of KeyTypes. A Template defines the form in order to manipulate the objects in the VME-DB.
- KeyType: This is the name of the object in the VME-DB
- Attribute: is the name of the attribute of a certain object
- TODO: Engineer and explain better the concept of Parent and Child.
Report, Delta and KeyValue
This diagram describes conceptually the model of a Report and the the format of a Delta message.
A Report is a collection of KeyValue(s). The Delta is a collection of KeyValue(s), representing a change of content.
KeyValue has the following attributes:
- KeyType: see above TemplateEditor
- id: is the id of the object in the in the VME-DB of a certain type(keyType).
- attribute: see above TemplateEditor
- value: the value for that attribute
Target
The target (VME-DB) is from a iMarine point of view a collection of KeyValue(s)
Webservice
Id management
When creating a new object on the side of iMarine, a reference or id for this object is needed. The responsibility of Id generation is primarily on the target side(VME-DB). What can be done is to generate an ID on iMarine side, according this convention:
ID = LOCAL_{localID}
Example of such an id would be: VmeId = LOCAL_452.
A delta can define a number of new objects with all local ids. Within the delta, the local ids have a meaning. When the ingestion webservice will create the new object in the target, a new object will be created and the local id will be replaced with the new ID.
Multilingual
The assumption is that multiLingual aspects can be covered also by only key values.
This implies that the Reports do not have to implement multilingual aspects. If the target (VME-DB) is multilingual, then Reports can handle that through key values.
Please verify this example:
| KeyType=Vme
id=10 attribute=Impacts value=20 |
KeyType=MultiLingualString
id=20 attribute=content value="Fishing activity has existed on the Corner Seamounts for many years, and catches over 10 000 tons were re-moved in the 1970s by USSR vessels, on seamounts both inside and outside the NAFO Convention Area, using a combination of bottom and mid-water trawling." |
KeyType=MultiLingualString
id=20 attribute=lang value=en |
Note: the above example describes also well in general how the key-value solution is envisaged.
Open Issues
- How to handle reference data, lookup tables (integration with the Cotrix Master Data Manager through a Master Data Client)
- How to handle validation rules
- The names of this iMarine function can be confusing: Reports. A report reports generally about 'something'. This function generates 'something', e.g. content. This function is all about editing content, to be send to another entity. Alternatives names could be UniversalEditor, InfiniteEditor, ContentCreator, etc.
- What to do if a delta corrupts the VME-DB? A solution could be to 'version' the VME-DB, so a previous version can be used in order to restore the website.
- How to implement the preview function of draft content? Also here versioning of the VME-DB could be a solution.
Stateful or Stateless?
The above picture assumes that the iMarine infrastructure will not hold state regarding the VME-DB. Content will flow from the VME-DB into iMarine, will be subject to manipulation and a stream of deltas will flow from iMarine into the VME-DB trough the webservice. In this scenario, iMarine is stateless.
The Stateful scenario would imply that the starting point of the lifecycle of the content is only within iMarine. The VME-DB is just an endpoint where the data is send to. The VME-DB will not hold primarily responsibility of holding the data in a meaningful and consistent way together.
Both scenarios have their pros and cons and FAO needs to speak with the iMarine experts which scenario fits best.
