[ForGr] List Support

[kvndrsslr]

Support Lists of Shapes (add a + button where multiple values are allowed)

• [x] identify the right DASH constraints and predicates
• [x] implement it for a minimal example
• [x] test it on more complex examples

[pskLana]

@kvndrsslr , let's take some example. Assume we have LinkingEnrichmentOperator. We add + button on the node. Would you like to see a dropdown list of possible shapes after pressing this button or/and a new node for chosen shape? (List of shapes for LinkingEnrichmentOperator: useML, linkingPredicate, threshold, selectMode, ...) or something else?

[kvndrsslr]

No this is not what I meant.

The idea is to explicitly describe in the shapes that some property can have multiple values. This can then be used in the frontend to generate + button which will in turn generate subforms.

Take for example some shape "siblings"(plural). A person can have multiple siblings. Therefore we specify in the siblings shape that it can have multiple "sibling" predicates which in turn must adhere to the "sibling" (singular) shape. The sibling shape might identify 3 important properties of a sibling: given name, last name and gender. In the UI, under the heading "sinlings" there should now be a plus button. On clicking it, a new subform (sibling-1) will be generated with input fields for given name, last name and gender. The shape might also specify that legal values for genders are only "female", "male" and "diverse". Then the input for gender should be a radio button group or Dropdown.

Please notice that part of this task is to modify the existing shapes with predicates found in the vocabularies I linked in the GitHub project description!

I unfortunately do not have time to read through the resources I have linked in the project description myself, so I cannot give you a thorough example of which predicates to use. But reading through the linked documents you will be able to get an idea how to implement this.

[kvndrsslr]

This is still high priority.

[kvndrsslr]

The PredicateConformation Operator looks like this:

However, target and source predicate should be grouped and the plus sign button should be present only once for the group. Then when clicking on the plus sign another group with the two properties should appear. The SHACL shape does also state exactly that.

For the Filter Operator it is not working at all: I see a selector property but actually there should be a group with its child properties and an accompanying plus sign. "selector" should not be displayed as property but as the title of the form sub group.

[kvndrsslr]

There are still issues in SHACL parsing. Example:

FilterEnrichmentOperator

Clicking on the plus sign gives an alert with "maxCount:1". However, according to the SHACL shape, this is not true. Please have a look at the SHACL shape:

deer:FilterEnrichmentOperatorShape_selector
  sh:path deer:selector ;
  sh:minCount 1 ;
  sh:node deer:FilterEnrichmentOperatorShape_selectorNode ;
.

deer:FilterEnrichmentOperatorShape_selectorNode
  a sh:NodeShape ;
  sh:property deer:FilterEnrichmentOperatorShape_selectorNode_subject ,
              deer:FilterEnrichmentOperatorShape_selectorNode_predicate ,
              deer:FilterEnrichmentOperatorShape_selectorNode_object ;
.

deer:FilterEnrichmentOperatorShape_selectorNode_subject
  sh:path deer:subject ;
  sh:maxCount 1 ;
  sh:nodeKind sh:IRI ;
.

deer:FilterEnrichmentOperatorShape_selectorNode_predicate
  sh:path deer:predicate ;
  sh:maxCount 1 ;
  sh:nodeKind sh:IRI ;
.

deer:FilterEnrichmentOperatorShape_selectorNode_object
  sh:path deer:object ;
  sh:maxCount 1 ;
.

These shapes have the following interpretation:

• There is at least one property deer:selector on each instance of deer:FilterEnrichmentOperator. No upper bound on the number of deer:selector properties is stated.
• For each resource pointed to by a deer:selector property from an instance of deer:FilterEnrichmentOperator, the following holds:
  • It can have at most one deer:subject property
  • It can have at most one deer:property property
  • It can have at most one deer:object property

So clicking on the plus sign should create a new subform for another deer:selector property instance.

[kvndrsslr]

A couple of things

Configuration Generation from Input + SHACL does not conform to the SHACL shapes

Right now, if I add two deer:operation to the deer:PredicateConfirmationOperator, the generated config will contain the following RDF subgraph:

deer:operation [
  deer:targetPredicate <urn:test:foo>;
  deer:sourcePredicate <urn:test:b>;
  deer:targetPredicate2 <urn:test:bar>;
  deer:sourcePredicate2 <urn:test:d>
].

However, the expected output is

deer:operation [
  deer:sourcePredicate <urn:test:b>;
  deer:targetPredicate <urn:test:foo>;
], [
  deer:sourcePredicate <urn:test:d>;
  deer:targetPredicate <urn:test:bar>;
]

I don't know where you got the idea to append integers to predicates but that is not how this works. RDF predicates employ bag semantics, which means that there can be multi-valued predicates per subject.

The SHACL document you are parsing in order to generate the UI does specify the shape of this data. If you have doubts on how to interpret it, please refer back to the SHACL specification. Additionally, you might refer to DEERs documentation (e.g. https://dice-group.github.io/deer/#/nodes?id=enrichment-operators ) in order to test / verify that the output you are generating is indeed what is expected.

UI: Problem with static text in button

With your new button "ADD ONE MORE SELECTOR", you would need to dynamically insert the name of the current predicate instead of using "SELECTOR" for every case. These predicates can have as many names as they like. I liked the + sign better.

UI: Need additional minus button

We should also include minus buttons to remove instances from the UI.