Generic patterns to edit RWW RDF graphs

Hello,

I'd like to know if some of you are thinking of patterns to edit RDF graphs
in the RWW world.


For exemple, suppose I want to edit a foaf:Person profile.
What I would like is to be able to edit the home locality of that person
for exemple.


I could do something like:

foaf:Person -> contact:home -> contact:address -> contact:locality


It is easy to follow this path, find a document and a literal node in
that doc corresponding to the locality and replace that literal with a
new one...


But sometimes an user doesn't have yet an address locality. So if I
map this RDF predicate path to a form input, it will be initially an
empty form input.
Once the user fills a locality and submit, I should create this
unexisting path to save the information so that it becomes available
under that path.


*But how does this path is supposed to be created? *

If a node is missing, should I create a named node or a blank node?

Should the nodes be created in the same document as the original one?

If we create these nodes in the same doc, how to handle different ACLs
for different part informations? I may have a public profile but not a
public address location.


If I want a different ACL for locality and the node doesn't exist:
Should I always create a new document?
In which LDPC?
Can I reuse existing documents that may already have the appropriate
ACL? For exemple documents that are in the Link header, sameAs or
seeAlso or things like that?


*If the path already exist*

With WAC acl, you may have a write access to a foaf:Person node
What if the foaf:Person node is editable, the address locality path
exists, you follow it, the locality node is stored in another
document, and you don't have WAC permissions to edit this document?

Should we create an alternative path so that we can provide a value
for the locality, while a value already exist but is read only?

For exemple, if you create your addressbook, you may not have write
permission on your foaf friends. Some of your friends no not mention
their address but maybe you still want to add an address to some
friend because you know it and want to keep it in your addressbook
privately.


*Which abstractions should we use in JS libs?*

I wonder if any of you have insights of good abstractions to use to handle
all these kind of cases, not only considering the case of a foaf person and
the edition of the address locality.

I think a good library should be customizable so that we can inject some
kind a strategy for each rdf predicate node we want to follow, but I'm not
really sure how to do it, neither what should be the default behavior

Maybe as a first start it can be nice to create all the new nodes as blank
nodes in the local document.



I'd like to discuss these issues. Can someone give exemples of complex RWW
foaf profile structures (using multiple documents with different ACLS on
different LDPC) that we should be able to handle in a good JS lib?


I think good abstractions are highly needed for RWW because we can't code
specific logic for each edit case. This would lead to a lot of noisy code
and the apps would be too hard to develop and maintain.



*Submit the new/edited data to the server*

What we have done so far at Stample is that when we edit a foaf:Person, we
create a new rdflib.js temporary quadstore initialized with the person
related documents. We modify this temporary person quadstore according to
user inputs.
Sending the data to the server means that we kind of diff the global
quadstore with the documents in the person quadstore so that we can send
requests to the RWW server to persist the new person state, and then merge
this diff into the global quadstore.

What do you think of this idea? Any alternative?


Thanks