The data layer view (rforms)
In Nuxeo we show a painting's data form that shows data from annotation point. View is built using a template and basically navigates through the RDF graph showing subject and object as data/sections (that is, Part 1 or Production) and predicates as labels (that is, "Has main part" or "Date").
Here are some specifics:
- We have a label at root level, representing the painting
- Some predicates and nodes are not explicitly shown. These are greyed out at the diagram below. For example, we don't have a label that stands for the P108i_was_produced_by predicate.
- Sometimes we have artificial sections/labels that don't correspond to data in RDF. For example, we have a section ""Title" that groups all P102_has_title's
- Some groups can be collapsed/expanded. This does not change the way they relate to RDF.
Annotations creation
Users create annotation by creating new discussions or replying to existing discussions. In Nuxeo each new discussions starts with a topic. The posts are added, replying to the topic or to other posts.
Each topic and post are annotations in RDF. Annotations discuss or propose a specific statement about a painting. For example, "Rembrandt was the author of Badende Susana". Annotations have the following properties:
- main uri: The painting they refer to. Always present.
- subject: The subject part of the statement they refer to. Present for all annotations except annotations about the root (the painting itself).
- predicate: The predicate part of the statement. Present for all annotations except annotations about the root (the painting itself).
- object (new value): Proposed new value. Optional. It is possible to propose new values only for literal or thesaurus values.
- other_object (old value). Existing value the annotation talks about. It is selected among all existing values (proposed, approved etc - all but "invisible"). Old values are set:
- If user selects the D button next to existing value (i.e. "Amsterdam" or "1636", or "painting"), this value is copied as old value.
- If old value is literal or thesaurus value, then user may change it or delete it. That is, old value may be null
- If old value is compound object (i.e. Production or Auction) it may not be changed
- When replying to a topic or post, old value is not copied in the new post.
- other object disposition: It has two values: Justify or Criticise. Must be present if we have old value in the annotation.
- disposition: Agree/Disagree. Optional. Shows disposition to the post the user replies to.
Reply to discussion/post
When replying to a topic or post the following fields are copied:
- main uri
- subject
- predicate
- other object (old value) and other object disposition - these are copied but user may change or remove them
Title is "Re:<previous post's title>"
Examples
Example 1
On the picture below we see how new discussions are created:
- At root level. That is, user wants to comment the painting itself. These annotations are not typical as they don't have subject and predicate. They only have main uri.
When creating such annotation, no new or old value may be selected. Predicate is also missing.
When replying to such topic/post, main uri is copied and cannot be changed. Below is sample screen for new topic creation on root level. Autogenerated title is suggested.
Main URI, subject and predicate are not implied. Old/new value fields are disabled.
- At "Has main part" level.
The "Has main part" label corresponds to the P46_has_main_part relation. It does not refer to particular part and this is why other object (old value) is irrelevant.
When topic is created, we set main uri, subject and predicate.
As this is just predicate discussion we don't preselect old object. And user can not enter one as this predicate relates to compound object (not literal or thesaurus). We check this by getting all versions for this predicate and checking whether they are literal or thesaurus values.
Getting versions is basically getting all annotation that have same main, subject and predicate and have new_value != null. The different new values give us all the versions. If there are no annotations we will find just the "invisible" (precreated) one.User can not propose new value because we have only compound objects as versions.When replying to the topic, main uri, subject and predicate are copied and old/new value cannot be changed as well.
Example 2
Here we have the whole triple selected and this is why we set other object (old value). As it is again compound object, we don't allow user to change it. They don't have to enter other object disposition as well.
When they reply with a post, other object is not copied.
Here is the screen for annotation at production level: 
Note that we need to extract label for rso:2926/part/1/production to be able to show it in the disabled field.
Example 3 
This is the most interesting example as it allows for editable old/new value.
The annotation at the "Date" label copies main uri, subject and predicate. Then user enters other value (old value) and sets other object disposition to "criticize". Then they suggest a new value - "1640". The E1 topic basically states that the user proposes to replace year of production from 1636 to 1640.
User input is marked with dashed arrows.
The difference between B1 ("Has main part") and E1 ("Date") is that B1 refers to compound object (Part 1) and user cannot enter old/new value while E1 refers to literal values and user is allowed to change old/new value.
When replying in the discussion (E2 and E3) we copy main uri, subject and predicate and user may change old/new value. When old value is selected (among all versions) user should enter other object disposition.
F1 may have "1640" as old value as it was already suggested by E1.
The annotation at "1636" is not very different. The main difference is that in F1 old value is preselected to what we have in data layer but user can still change it.
Screen for E2:
Retrieving discussion
When retrieving annotations following rules apply:
- at root level we have only main uri fixed. We select all annotations that have the same main uri. This effectively selects all discussions for the painting and the nested data.
- at predicate level we select by main uri, subject uri, predicate uri. There are no value constraints. This would select discussion with old/new value as well.
- at field (data) level we match main, subject, predicate and (old or new value to be equal to the selected data field - "1636", for example)
We need the (new or old value) constraint because of the following scenario:
- Let's have "1636" in data layer
- A user creates an annotation and proposes "1641"
- Project administrator approves "1641" and it gets into data layer instead of "1636"
- When user selects "1641" via the D button they need to be able to see the annotation it was proposed with - and it has just new value
