VIVO-1013: Should the ABox include all graphs that are not in the TBox?

[chenejac]

Jim Blake (Migrated from VIVO-1013) said:

We have used the tacit assumption that the Full model is equivalent to a union of the ABox and the TBox. In actuality, however:

The Full model is the union of all named graphs in the triple-store

The ABox is the union of http://vitro.mannlib.cornell.edu/default/vitro-kb-2 and http://vitro.mannlib.cornell.edu/default/vitro-kb-inf.

The TBox is the union of http://vitro.mannlib.cornell.edu/default/asserted-tbox and http://vitro.mannlib.cornell.edu/default/inferred-tbox.

This means that if an installation creates their own named graph, then that graph is in the Full model, but is in neither the ABox or the TBox.

This has already led to a problem, VIVO-934, and may well lead to others.

[chenejac]

Benjamin Gross said:

I am interested in this issue. I prefer workflows where I can put triples into different named graphs, but triples not in kb-2 cannot be edited through the UI. There is no error raised when trying to edit values in a custom named graph. The form submits successfully but the value is not changed.

[chenejac]

Jim Blake said:

[~accountid:5bb229e412ef2d4bf3a2233d], your comment is somewhat tangential to the reported issue, and not easy to remedy.

The thing is, all editing is applied to kb-2, because it's not clear when it should be applied to other graphs instead.

Let's say you have a triple in http://this.graph like this: a:someGuy rdfs:label "Guy, Some" and you want to change it to: a:someGuy rdfs:label "Guy, Som E.". what happens?

VIVO will try to delete the first triple from kb-2. That triple is not found in kb-2, but the attempt to delete a non-existent triple is not considered to be an error. Then VIVO will add the second triple to kb-2. So now we have two labels for a:someGuy, one in http://this.graph and one in kb-2. Which one will be displayed? I have no idea. Hence, broken.

But what should the behavior be?

In this case, we might determine that this is actually a replacement (and not a deletion followed by an unrelated addition). Then we could determine which graph was affected by the deletion, and then do the related addition in that same graph.

But what about a less obvious case? Perhaps we want to say that a:someGuy (in http://this.graph) is an author on a:someArticle (in kb-2). Which graph should contain the authorship node? Which graph(s) should contain the triples that connect the authorship to the author and to the article?

Not saying that these questions can't be resolved. Just that they will require thought.

[chenejac]

Benjamin Gross said:

I do see the challenge in addressing the points you make.

My thinking is that, if you are editing a value, it should be possible to make the edit controller aware of what graph the data you are editing originates from. That way the delete and add can be performed on the correct graph.

Another line of thought that would probably be controversial is to adopt a multi-graph schema where every entity and property is assigned to a specific graph. Could base them on class and property groups.

 

[chenejac]

This issue is related to #922