Data Package Support

[p-a-s-c-a-l]

The Map Component must access the meta-data of the Data Package (Example: Background Layers) of the current Study stored in the CSIS via the JSON API and initialize the LayerControl Component with the respective layers. The LayerControl Component must support grouping of layers into different categories. Relevant properties to define the groups are

• data_resource/title: title of the resource in layer control element
• data_resource/path: the URI to build the WMS/WFS request. Needs possibly to be parsed and bbox request parameter to be provided
• data_resource/analysis_context/workflow_step: for now we show only layers that are valid in the current context (so no subfolders for different steps)
• data_resource/analysis_context/resource_type: Can be used for top level categories (folders) like background layers
• data_resource/analysis_context/scenario: could be used in HC, HC-LE and EE (IA currently under discussion) for sub-level categories

This information provided in properties of the Data Package / Data Resource should be enough to build and initial categories tree for the Map Component / Layer Control:

If additional categorisation is needed (example in figure below), the Data Package specification has to be extended.

[maesbri]

I am not that sure that it would require extending the data package specification.
Following the above example for the population, to me, those are three population density data resources contained in the data package, with their own properties values.

[p-a-s-c-a-l]

Yes but how to decide if an exposure resource is put into the folder population or buildings if there is no additional categorisation property at the level of the data resource and the Data Package contains several Exposure resources (identified by data_resource/analysis_context/resource_type) that belong to several logical categories?

[maesbri]

Indeed, we need a 'category' property with possible values: population, buildings, etc....

The more I think about all these specific parameters, the more I am convinced that we should have a general resource with common attributes and the specialized resources (for BackgroundLayer, Exposure, Impact, etc.) with their specific properties, like the category for the Exposure and Impact analysis.

I need to think a bit about it since this would also introduce other problems, like repeating the same resource for each of the steps in the workflow where it is used.

[p-a-s-c-a-l]

We'll try to define a REST View to simplify the extraction of the relevant properties from the study and data package entities. See clarity-h2020/csis#22 (comment)

[patrickkaleta]

@therter
so for now I created two REST Views:

• the REST Group View with the display: Map Component (/admin/structure/views/view/rest_group/edit)
  -- it returns the links to the second REST view for each resource in the data package used by the study
  -- path: /rest/map-component/study/[StudyID]

• the REST Node View with the displays: Map comp. dataset and Map comp. analysis. context (/admin/structure/views/view/rest_node/edit)
  -- Map Compoment dataset returns the title and path of the resource and the result of the Map Component Analysis context (workflow_step, resource_type and scenario)
  --path: /rest/map-component/dataset/[DatasetID]

I'm not sure if this nested View approach really works (meaning the JSON result is valid but it might be difficult to parse the result), so please check this and if necessary I will change this last part and return only the link to the Map Component Analysis context display instead of its result. The whole process would then take in total 3 calls instead of just 2, but since you mentioned that this wouldn't be a problem for the map compoment, we could do it that way.

[p-a-s-c-a-l]

@patrickkaleta @fgeyer16

What's the relation of Rest Views to the JSON:API vs. core's REST Module? We should't mix APIs so we have to make a decision for either JSON:API or REST Module!

[patrickkaleta]

@p-a-s-c-a-l
Building REST Views is a feature of the Core's REST module. I'm not aware of the JSON:API being able to filter out only the fields which we require. I would have to look into that.

[fgeyer16]

@p-a-s-c-a-l @patrickkaleta
JSON API has a Filtering functionality as you can read here. And I just read that you can embed referenced entities with JSON API. Which would be a possibility to reduce REST calls here: clarity-h2020/csis#22
This would speak for the JSON API. What I do like better on Rest views is that the Interface is nicer. What I mean is that you do not have to create a big HTML query string for filtering if a great part of the filter is always the same and only one or two parameters are exposed to the user of the interface.
Since there is the idea of csis being open to service providers for integrating their own service a "easy" REST interface is maybe more appealing to the service providers.

Do we want to have a API which delivers a big amount of data (from which we maybe need only a small piece) with one call. Or do we want a more talking API where we have to ask for every piece with a separate call? The second case is maybe better if the external services have a lot of logic inside and need different data in different cases.

What do you think?

[p-a-s-c-a-l]

I'm in favour of the JSON API as I have the impression it will replace the REST API in the long term. While it's true that it's up to the client developer to build some complex query strings (once!), it gives us more flexibility and reduces maintenance effort and complexity at level of the Drupal side (no need to create REST Views for each and every special case).

What I don't like is the is the structure of the JSON documents, that's far from being clean and simple. Those aren't the javascript objects you really want to work with at client side. Referring to the example (which is btw rather confusing with its mixture of id, uid and uuid), I want to access article.comment[0].user and not iterating over included arrays by data.relationships.field_comments.data[0].id and relationships.uid.data.id.

So we have to put more effort in the client logic that maps these complex JSON objects into the simple state models of our applications (see point 3 and 4 in this issue). But I don't expect that the JSON you'll get from the REST Views will look much better.

[p-a-s-c-a-l]

Basic Data Package Support is available. Now we have to deal with the changes to the DP Specification.