Open jeff-zucker opened 2 years ago
The way the forms pane deals with ambiguous/impossible write locations is to have an explicit http://www.w3.org/2007/ont/link#annotationStore
.
Loading the cross-document graph in memory is not a problem - everything is in the rdflib store anyway as long rdfs:seeAlso
links are dereferenced.
If I understand correctly, this issue refers to the pane implemented in https://github.com/SolidOS/solid-panes/tree/main/src/profile . Does that then mean that it will be obsolete with https://github.com/SolidOS/profile-pane ?
This might end up being a bug in solid-ui
that some form components don't display or allow editing across document boundaries. I think I've seen that problem before but would need to get a reproducible example.
Not sure if it's related in the end, but here's the example I had in mind in which a form struggled with document boundaries: https://github.com/SolidOS/solid-ui/issues/535
If I move the foaf:knows triples from my profile to a file linked from my profile with rdfs:seeAlso, the show-profile page can find them, but the edit-profile page can not. This is because the form to edit the profile is based on the profile document, not the profile graph. [EDIT: following suggestion is probably unworkable because where would you write the data back to?] One way of solving this would be to use something like solid-rest-browser to store the profile graph as an in-memory document and edit the profile using the in-memory document as the data-source of the form.