Re: Generic patterns to edit RWW RDF graphs

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

>
>
>
> On Wed, Feb 12, 2014 at 1:18 PM, Melvin Carvalho <melvincarvalho@gmail.com
> > wrote:
>
>>
>>
>>
>> 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.
>>
>
>
> That seems right, let's always use named nodes then :)
>
>
>
>>
>>
>>> 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
>>
>
> Thanks will check that
>
>
>
>>
>>
>>
>>>
>>> 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
>>
>
> It seems that TimBL is using sameAs in his foaf profile (this is why we
> had troubles displaying his friends :p)
>
> Also, I noticed this ontology used in its file:
> http://www.w3.org/ns/pim/space
> Can it also be useful?
>

Yes, this is very useful!

Basically a user has preferences.  In your preferences you have workspaces
(public/private/shared) where client side apps can store remote data.

No other system puts the user in such control of how and where they store
there data.  This new type of storage is being termed, I think, "Personal
Data Stores/Spaces" (PDS)


>
> Basically what we want here seems to be the possibility to extend a
> resource with additional graph sources (like a resource extension),
> protected or not, that we may consider having the same level of trust than
> the original resource (i guess). Maybe the ontology could also indicate it
> it's worth fetching these additional sources because we don't want to fire
> useless requests just to realize that we don't have access to any of these
> resource extensions (particularly when visiting content we don't own).
>
>
>
>>
>>
>>> 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?
>>>
>>> Any idea on that? if it is possible to reuse such an ACL protected
> document extension, I guess when using a lib I should be able to specify
> the ACL I want and then try to match this ACL against any of the
> extensions.
>

Not sure on this one, I think the ACL is normally one rule per resource,
but im not 100% sure.


>
>
>
>>
>>> *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.
>>
>>
>
> Why not? If I am friend with someone who have a locality I can add him
> another locality in my local graph for exemple.
> Btw I don't really see how a good IHM can ask an user to request an access
> on a single user field. I simply don't really know what to think about
> these cases.
> Maybe if you have read permissions on the foafPerson doc and you want to
> edit the address on which you don't have access you could also create
> another address in another doc and change the link that you can edit on the
> foafPerson doc (yes that would leave the old address being isolated, the
> node still exist but nobody referes to it anymore)
>

Maybe one way is that the user has an area where you have "append" access,
sort of like an inbox.  The inbox then gets processed manually or
automatically and the request then propagates into the main files, either
with an approval or straight away.  Would need to try out the workflow I
think...


>
> 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?
>>
>
> Please tell us :)
> For now we mostly use Henry and TimBL profiles
>

Follow your nose from either of these profiles and it goes several million
deep!

Kingsley: any views on this issue?


>
>
>
>>
>>>
>>> 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 ...
>>
>
> Is there any opensource code for that?
>

Sure virtuoso have an open source version

http://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main


>
>
>
>>
>>
>>>
>>>
>>>
>>> *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
>>
>
> Hmmmm this is pretty basic stuff, our usecase is not to edit a single node
> in a single document.
> Rather we may stage modifications to a temporary store and then flush them
> all to the CloudStorage server on user validation.
> What we want is probably more advanced because once an user validate its
> profile modifications then multiple documents may be updated in the same
> time. We may potentially need to handle concurrency issues with etag 412
> error code and suggest some kind of "merge mode" to the IHM in such case
> (it will be quite complex code and UX design I guess)
>
>
>
>>
>>
>> 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
>>>
>>>
>>>
>>>
>>
>