brgm / registry-core Goto Github PK

Sent to every role

• admin : overall vision
• submitter : only on what he submitted

About changes on content and structure. Every change is to be notified

Add the possibility for a user to refine what notification he will receive

Notification message : URI, who, what, when ?

-> dev needed

Hinting mechanism generating warnings if a prefLabel, description etc... is already being used

• in the same register
• throughout the registry

Triggered

• when editing an item
• when doing bulk upload ?

Questions :
capacity to upload to upload new 'test suite' VS hardcoded set of tests run everytime

Dev : needed both for back-end and GUI (hinting)

Target is the main template (the page body, not the rendering of each register content)

Allow to have a different template according to the registers 'categories'
Example:

• geology -> a graphic charter
• water -> another graphic charter

Idea

• graphic charter to be used defined on a register by register basis or by category
• in velocity template (s) VS modification in the GUI (like loading a Drupal theme)

-> Dev: needed

• Each template (graphic charter based) should be available on the server
• And admin shall define (point to) which template to be used

With

• image/logo of the source to which we are mapped (ex : http://resource.geolba.ac.at/lithology/251.html (with INSPIRE logo))
• a label

Example, if mapped to http://inspire.ec.europa.eu/codelist/LithologyValue/amphibolite ldregistry admin could define

• base URI: http://inspire.ec.europa.eu
• logo : upload the INSPIRE log
• label that should be displayed each time the system encounters the baseURI

provide a way to modify the structure or the values for all entries without doing them one by one. (ex: typing them all with an additional class) without a export-reimport loop.

• Dev needed.

Why : not everyone understands skos, rdfs, rdf properties name. especially if we also take into account multilingual context

Expected behaviour example for skos:prefLabel
EN: Main denomination
FR: Libellé

How:

• solution A via properties file as well to support i18n (xPath / traduction) -> quick & dirty
• solution B : define an ad'hoc ontology / register (mimic what's done for links: https://data.geoscience.fr/ncl/system/links) and have the Velocity and Java use it

-> Dev needed. Solution B looks more realistic to us

To administrate the registry, we need to define correspondence between roles and status for accessible registres. Maybe on the conf level.

• dev needed: need extension on the permission module?

Need for workflow metrics

• ex: amount of days between update proposal by a submitter on a registerItem and its validation

-Dev needed

Need to visualize picture if a url is included in the description of registre/entry via properties such as foaf:depiction.

dev needed in frontend. simple

need for a send comment button about a register or an entity

• dev needed in frontend. simple

Keep Experimental and Stable status even if we add our own entries.
They don't re-appear if recreated manually in the lifeCycle register

-> dev : looks like a code change

Example https://data.geoscience.fr/ncl/?entity=http://inspire.ec.europa.eu/codelist/LithologyValue/amphibolite

Idea : involve the same mechanism as the one defined for the image+logo (see #12)

-> dev needed

ex: https://data.geoscience.fr/ncl/apt/1094.ttl

-dev needed on the backend

When adding a register entry, Need for an empty template with 'mandatory' properties awaiting values in the form, and a list optional ones proposed

dev needed:
- on the GUI level
- validation

ideas: -stating the properties template so that the GUI knows what to display

• using SPARQL query to check the existing payload

Under advanced\import
When uploading a new register (csv, ttl,...) for replacement
The response immediatly received is 'Steam already closed...'

Solution : only works propertly uploading nQuad (with all metadata)

Dynamically generate .ror files as specified by INSPIRE group on register federation:

• registry ror file
• ror descriptor for each register you want to share in the federation.

More details and example files here: https://ies-svn.jrc.ec.europa.eu/projects/inspire-registry/wiki/Registry_federation_requirements

Running examples (hand-made for BRGM registry)

• for the registy https://data.geoscience.fr/ncl/registryFederation.ror
• for one register :https://data.geoscience.fr/ncl/litho.ror (example, search for dct:accrualPeriodicity).

Idea would be to have the required 'descriptors' natively included in the description of the registry and the registers -> no more need for static files but need to have a new 'download format' (like RDF/XML.ROR) that triggers the required response/serialization

have different views/representation view of a register, such as bubble graph.
(ex: http://resource.geolba.ac.at/lithology/251.html)

• dev needed

On https://data.geoscience.fr/ncl/par

Asking for RDF TTL -> not all the entities that are in the SPARQL endpoint are downloaded

Idea

• serialization heap space issue ? -> logs
• TODO SG : check VM conf : CPU n°, Java XMx & friends for better issue description

Properties file to allow translate the GUI (we need French :) )
-> dev to be done for i18n

A need for dashboard:

• On the global level (new entry page)

• For a giver register

• dev needed

As it has been discussed the registry federation works only with namespace forwarding and delegated register. The Registry federation as described in here doesn't work as intended.

Having the functions described in this part of the wiki must be enough for our needs.
Do you need further information to see how this could be added

Allow a user (machine, human) to subscribe to a notification system (a Kafka topic for example) and receive the corresponding notifications.
a notification stream (Kafka topic for exmaple):

• by register
• at a whole registry

There is no JENA plugin yet for Change Data Capture as opposed to what we have for relational DB.
But there is an existing process notification sytem in ldregistry loggin each request. This would be a good starting point.
Building on process notification, it should be straightforward to have a Kafka module

Note

• Epimorphics is working on the Kafka topic on his side
• BRGM is investing on a Kafka based notification system for its information flows

On

• the landingpage
• the description of a register entity

No direct ability to have a diff between 2 versions.
In the current version, only links between different version are encoded in metadata items.

• Dev needed

So far not feasible be it at register or a register entry level
Without deleting notation, type and label.

-> dev : easy

So far no moderation on actions (we only have roles).

Need to have validation by admin/manager on create, update done by a submitter on a registerItem.
Edit can be either content or structure (add/remove property)

-> dev needed

Have pure SPARQL between ldregistry and the underlying triplestore

Need to have an official V2.0 release (still Tomcat 7).

• dev: apparently no blocking factor for a 2.0 release still Tomcat 7