Re: Generic patterns to edit RWW RDF graphs

On 12 February 2014 12:17, Sébastien Lorber <sebastien@stample.co> wrote:

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

Yes!


>
>
> 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.
>
>
I think so, if the resource is writable that's the ideal place for it.


>
> *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?
>
>
You may.

Some people dont like to ever use bnodes.  There's an axiom that states
that anything of significance should be given a URI.  But bnodes are legal.


> Should the nodes be created in the same document as the original one?
>
>
They dont have to be, but it would make sense, imho


> 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.
>
>
Currently we tend to have ACL on a per document basis.  Some people have
done work on a per triple basis ACL, though that may not be as RESTful.

e.g. http://ns.bergnet.org/tac/0.1/triple-access-control.html


>
> If I want a different ACL for locality and the node doesn't exist:
> Should I always create a new document?
>
> Good question.  I chatted about this with Henry once and he suggested a
"protectedSameAs" subclass of sameAs ... but we never created this.  I'm
not sure of the answer here, but it's an important use case, imho


> 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?
>
> Then I suppose you need to request access?

Note: Dont forget in RDF data is a set, so you need to be sure you want to
delete the old one and add the new, rather than adding another locality.


> 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?
>

Perhaps Kingsley has some?


>
>
> 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.
>

+1 agree, I think this is an important use case to solve

I think openlink may have a way to do this already ...


>
>
>
> *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?
>

HTTP PUT
HTTP PATCH
SPARQL UPDATE

Are some ways.  I've made a little demo with code here for these 3 methods:

http://hello.rww.io/hello.html

There's also Talis changesets and The web payments folks are working on
something too:

https://web-payments.org/specs/source/web-identity/#writing-data-to-the-identity



>
>
> Thanks
>
>
>
>