Allow any form field to be represented by reverse arc in the graph

[timbl]

All the form fields at the moment assume that they are given a subject X and a predicate P and the form will write a quad (X, P Y, G).

In fact, when not dealing with literals for Y, RDF is symmetrical: it is just as reasonable for them to correspond to the data (Y, P, X, G). So we need to be able to specify in a form, that a given field is in the inverse direction.

Examples:

• When a user is a member of a group, the triple (user, member, group) could turn up in a form about the user - or a form about the group.

• In a family tree user interface form, the same form could allow adding a number of (this, child, Y) triples to list one's children, and also a set of (Y, child, this) triples for giving ones parents.

[timbl]

This means basically going over forms.js and every time property is involved, including inverse. Including making the form field labels -- there is somewhere the code to generate inverse labels

[RubenVerborgh]

Inverse properties might also pose a usability problem, because the direction is different from what people expect. Easiest thing to do, both technically and usability wise, might be to infer the inverse triple and take it from there. (We don't even need to assume that the corresponding inverse predicate exists; we can just mint a "blank" one that the user then can name.)

[timbl]

@RubenVerborgh When you say " because the direction is different from what people expect." presumably you mean "developers". End users should see nothing different from normal. Suppose we distinguish between two sorts of developers, ones who are making a quick app within a system of shapes designed by other people, and those are designing a system, the ontology/schema engineers, then the first set maybe should have that papered over, but the second set should understand the graphs.

[timbl]

One possibility is to just add an "inverse" flag. Another possibility is to use SHACL path shape, which allows multiple paths including inverse and forward.

[RubenVerborgh]

presumably you mean "developers". End users should see nothing different from normal.

I did mean end users. I agree that they should not see anything different; my argument was that this is not always easy to achieve, and probably easiest to achieve through an actual inverse property.

For instance, there would need to be a fitting inverse label. Things like “is has supervisor of“ only work to a certain extent. So we could introduce an inverseLabel construct, or just mint the inverse property and label that one (which I think is easier).

[timbl]

Certainly adding a flag to the form field is simplest to implement for the form system. I'm thinking "reverse" as opposed to "inverse" as the arc is a reverse direction. "inverse" is a relation between properties

[timbl]

I guess it is going to be unlikely that people expect to be able to use reverse arc with any literal value fields, as it normal for the subject of RDF not to be a literal. That simplifies this. (NamedNodeURI field would be an exception, as it creates a named node)

[timbl]

By the way, the field label code already does the right thing when labeling a 'Is child of" link: if you have another property linked as inverse and having a label, it will use that. That inverse property can be a bnode in fact, and is in some cases. so

  :child rdfs:label "child"; owl:inverse [ rdfs:label "parent" ] .

works fine in the solid-ui predicate label function.

[timbl]

The current release of solid-ui includes a boolean flag ui:reverse on the Multiple feild, which causes the form to set the subject rather than the object of the triple.