buda-base / blmp-prototype-flow

Prototype of BLMP client, implemented using flow.

Vagrant scripts for BUDA platform instanciation

The base platform is built using Vagrant and VirtualBox:

1. Install Vagrant and VirtualBox.
2. Download or git clone this repository.
3. cd into the unzipped directory or git clone
4. install VirtualBox guest additions with vagrant plugin install vagrant-vbguest
5. run vagrant up to summon a local instance

Or for an AWS EC2 instance:

1. install the vbguest plugin: vagrant plugin install vagrant-vbguest
2. and run the command: vagrant up or rename Vagrantfile.aws to Vagrantfile and run vagrant up --provider=aws

This will grind awhile installing all the dependencies of the BUDA platform.

Once the initial install has completed the command: vagrant ssh will connect to the instance where development, customization of the environment and so on can be performed as for any headless server.

Similarly, the jena-fuseki server will be listening on:

http://localhost:13180/fuseki

Lds-pdi application is accessible at :

http://localhost:13280/

(see https://github.com/buda-base/lds-pdi/blob/master/README.md for details about using this rest services)

The command: vagrant halt will shut the instance down. After halting (or suspending the instance) a further: vagrant up will simply boot the instance without further downloads, and vagrant destroy will completely remove the instance.

If running an AWS instance, after provisioning access the instance via ssh -p 15345 and delete Port 22 from /etc/ssh/sshd_config and sudo systemctl restart sshd. This will further secure the instance from attacks on port 22.

blmp-prototype-flow's Issues

spell check setting according to language

When a string is tagged as English (in RDF), it should be made clear to the browser so that the English spell checker gets triggered by the browser. Same for other languages, maybe integrating custom spell checkers in the future.

When selecting a resource and clicking on its object properties, only those which are descendants of :Entity should open the right panel

The right panel should display information only when clicking on resources on the left panel which are:

• entities (type :Entity)
• or which are descendent of entities

Entities are all resources which are of the following types: Agent, Etext, Item, Lineage, Place, Topic, Volume, Work.

X is a descendent class of Y:

• if there exists: X1, X2, ... XN avec N >= 0
• such as: X rdfs:subClassOf X1 rdfs:subClassOf X2 rdfs:subClassOf ... rdfs:subClassOf XN rdfs:subClassOf Y

Different ways to express the same concept:

1. object properties which range is a class which is a descendant class of :Entity (or which has for ancestor :Entity)
2. object properties which range is not a descendant class of :Facet or :Event
3. objects which class is not a descendant of :Facet or :Event

Add all the issue and improvements to be done in Github Project & prioritise them

• Create a new GitHub project
• Include the current GitHub issues
• Raphael to review his Trello tasks, and add them in this GitHub project
• Nicolas to review the email sent to Raphael based on this discussion between him and Chris (check green highlights), clarify each task, and add them in this GitHub project
• Nicolas to check the previous GitHub project, clarify each task, and add them in this GitHub project
• Elie to review his notes and clarify each task, and add them in this GitHub project
• Elie / Chris to prioritize each task

Develop a Javascript RDF Patch library

Chat with Elie

• Develop a library using the same API and data model than the RDF JavaScript Libraries which would allow us to create patches
• independant library, published on npm
• the idea would be to make it generic so that we could give it to organization behind RDF JavaScript Libraries so that they could take care of its maintenance
• to handle our specificities, like the "taskid" in the header, we could have a method which handles what needs to be put in the header
• could be pretty simple using a naive approach
• its API should be pretty similar than the Java library. Chris knows the code, she will be able to guide me on the most interesting fonctions

url should be local

The urls at src/api/api.js line #'s 248 and 264 should be local so that blmp is using the local lds-pdi rather than the one at buda1. If the blmp is running on buda1 then it will automatically be using the lds-pdi on buda1.

Or perhaps some other configuration approach that allows to easily switch where the lds-pdi is.

inpiration from wikidata

The wikidata editor is a possible source of inspiration. It doesn't have special qualities, but has the advantage of being something similar to what we want to achieve and is used in production...

example : https://www.wikidata.org/wiki/Q445460

auth integration

We should integrate a login facility for users. In a first time it should just allow users to log in and display their name, and in a second time when the server will be ready, the auth token will be transmitted. We'll be using Auth0 which is an OpenIDConnect (or oidc) which is a layer above OAuth2. These are all widespread standards and some high level libraries exist, see this one integrating Auth0 and React. It's not an emergency but that would be an interesting first step in the low-level plumbing.