Re: Solving the "Deep Linking" (bookmarkability) problem in RWW for single page applications

reading your mail; you’ve got an application that lives somewhere; the principle is that the app doesn’t store user data; rather, it goes seeks it from RWW-LD Services.

so; functional example;  mindmup.com - it stores on gDrive to support collaborative sessions.  You have to go into your gdrive permissions, and set the ACL’s to collaborate.

in-turn; a ‘social network’ page - where the tradition says, it has a graph of friends, photos, posts, etc. 

i’m assuming we’re not in a world where ACL’s don’t exist; and acknowledge, that some ACL’s may be set to public, whether that permission is applied to derivative info; or master data.   example; GPS Data on an image - a derivative might be ‘australia’; master data = gps long/lat point data. 

Regardless of what’s actually stored in your friends rww-service (or services, they might have a bunch of them woven together) you’ll only see what’s available to you.  perhaps there’s multiple persona (i.e. one set of information in linkedin:business; another in Facebook:HOME, etc.); but your only using one ‘persona’.  perhaps they’ve got ACL scripting that lowers resolution on images for ‘public’ info; perhaps friends get one creative commons attribute - public get another, upto the user really… 

they’ve got you in a graph defined in their RWW system; which provides you limited access. therein; the entire service is not exposed to you, only what (and how) they’re happy to share. 

technically; http://phpcrawl.cuab.de/  comes to mind (mind, need to render rdf rather than mysql) in principle; the rww service needs to support basic functions. another basic function would be parsing image metadata, offering a means to support image derivatives. I think in the method you’ve described, your assuming the server-side of the RWW environment cannot support some of the alternative methods, providing solutions required by your app.

whether the rwwserver is on rww.io, data.fm, stample.co ods or some other url / server technology that conforms to the rww-ld spec (and i think we could start by defining a name for this thing); it shouldn’t matter where user-data is stored; and some basic functions are required to support apps targeting a common method to target data-services on these platforms.

Your ability to render your friends rww.data is based on what is available to you; so, in a way it’s a unique inference of the friends graph.  Perhaps that’s stored and time-stamped, so updates can be applied, perhaps .well-known/rwwproxy needs to exist.

so; from a end-user perspective; your session is carried out on www.yourapp.tld and that app; depends upon people having their own rww-ld service accounts, with a range of ‘common’ functionality.  

Another way of doing it might be that your app has a WebID; where users can assert ‘cache’ permissions.  in most circumstances, an app.developer would want some amount of CRM data in any case.   I imagine the best path probably relates to the path of least data transit / storage. i.e. a method with least energy.  But in any case, i’d like the weblog stored on my rww-service. 

i think it’s all new; we’ve only got ideas. 



On 13 Jan 2014, at 7:32 am, Sébastien Lorber <sebastien@stample.co> wrote:

> Hi
> 
> Sorry Tim but I'm pretty new to this RDF / RWW world and I don't really understand what you are trying to tell me.
> 
> 
> Melvin yes I guess it could work
> 
> 
> 
> 
> On Thu, Jan 2, 2014 at 3:30 AM, Tim Holborn <timothy.holborn@gmail.com> wrote:
> hello.
> 
> 1. perhaps the worry about refresh is actually a need to 'stream' data, and that most of the RDF Graph Data is distributed (acquired) rwwserver (or just simply RDF) to rwwserver. 
> 
> 2. caching - thinking neurally; i think about permissions systems, the base WAC methods.  i recon it's not one big brain, it's perhaps better described as a neural network of knowledge units; connected via authenticated communications to others.  each object has a unique identity, which is described somehow (i.e.: WebID's) and like synaptic nerve cells, ACLs can help define how to build bridges between knowledge units.
> 
> Behaviourally; we've got stuff in our heads.  Sometimes we'll seek to learn from others, sometimes we'll just depend on them being around, when we've got a question we know they'll be able to provide a solution; if it's important, we might ask a bunch of people so we're more capable of determining the best path forward / decision making process or method.   Sometimes, if there's references we don't understand; we'll write it down in a language we understand, then look it up, using other resources. 
> 
> 3. There's a few different user cases, and i think it depends on the subjectAltName method used with the webid. if it's a foaf record, then it's about people; but it might be about an asset, or a description of a public thing; or a project with public / private members, or a nav.target for a deceased person, linking to external resources (birth certificate, photos, residential places, book references, etc.).  The SPA needs to identify how to syndicate data, at runtime; and within that process, is the question of how its then formed into a knowledge method. 
> 
> THEORY: TIMH (WebID:FOAF) has a computer he uses (WebID:desktop) with his RWW system (WebID:rwwserver.account=profile2('ubiquitous')).  TIMH has logged in using desktop to his profile2 account, which he authorises to go do stuff for him in that session, with whatever app his using on his desktop or other authorised machines; subject to the definitions his provided, or the 'rule book'. 
> 
> Browsing FOAF:KNOWS; authenticated via authprocess+webid's;  i goto seb(profile1) FOAF:KNOWS, then a request is sent to profile1: rwwstorage to get available foaf:knows from my rwwserver/server; then fetch related graph data, and cache it. method then goes, looks at WAC, gets the data i'm allowed to get, stores it on my RWWSERVER - then feeds it to my desktop from my rwwserver.  Perhaps has checksum or something; so, if desktop gets rebooted; i need to go back to that 'view', my rwwserver goes asks if anything has changed; and if it has, send update, if not - lets save some energy; it might also have a save button, so i can name it as something and store it somewhere in my rwwserver (i.e. convert it into a WAC 'circle') 
> 
> so: in applying the theory with an information workflow;
> 
> Hi Seb (profile 1).  I'm timh (profile 2).  i see you've got an email address (which could link to DOAP? & FOAF?) and via public-rww (doap?) i've received an email (micro-blog?) which is assigned to my graph (profile 2) via public-rww (doap?) with provenance from you (profile 1+vars).  
> 
> If users have rwwserver.io accounts: they've got server side webid's? connected to ACLs (WAC); each user has their own session to their own system; and the server side of their instances, have peered connections between each server-side profile. 
> 
> if i want to share a link with you; then, i connect to my rwwserver environment (perhaps for now we'll call it a pop3/smtp interface/socket) i scribe you some info; insert a link http://www.layoutit.com/build# (RDF:DOAP:DEVLINK (i know that's wrong..)( https://github.com/justjavac/layoutit ) and that amends to your graph; perhaps with a rel:profile2 rdf method. 
> 
> (Perhaps part of the benefit is that data centre bandwidth is generally more easily obtainable; than last-mile connectivity, and in the interests of accessibility; lowering client-side bandwidth, will help accelerate adoption.  geeks can make funky proxies too…  mostly in data centres i suspect…)
> 
> You can't share your friend; you can only share what they've shared with you, and in-turn, allowed you to share with others (perhaps a blocking list can also be asserted by some form of uid?  i.e. ex.wife + mutual friend might = trouble?), which might have terms or permissions associated to it, described (for example using a mind mapping like tool, to write) in RDF (creative commons, etc.).  In your graph; you've got permissions that have been provided p2p (server side) over assets provided by profile 2 / 1, project 1 / 2 / etc.   those permissions might include copy or fork permissions; with or without creative commons rdf, for example.   I like the example of a historical societies picture; they'll provide it freely to education, but if a newspaper wants to publish it, it's probably better to get a little revenue for commercial use than putting their hand-out for public funds; and using RDF, doesn't matter if the newspaper sourced the image from the educational source, or the historical society (as a provenience example).
> 
> Provenance is important; and whilst caching permissions might allow 'keep forever' (obviously PDF has some of those functions anyhow), i think there's big storage benefits (energy consumption) from caching data, rather than keeping data copied all over the place, mind; that also inter-relates to accessibility (over time, etc.), preservation and other considerations (some of the swarm methods could be economically rationalised; and what i'm trying to consider here, is the question in economic terms; when advertising / data mining isn't allowed.) 
> 
> WAC can obviously describe 'public' as a permission state; perhaps defining whether webid:foaf  is required or not. 
> 
> Then to make things more complicated, as a SPA may be somewhere else; i recon the rwwserver is simply a storage / webid / RDF - linked data server function.  The SPA might be Taskify; or lifeshare or layoutit or mindmup, etc..  
> 
> so perhaps we need a server side proxy.js ?  i think therein; the URL is masked, but a 'link' can be embedded into SPA - which in theory might associate to history.js following your logic? (bit like google maps); this in-turn could be exported as a RDF Object (stored on rwwserver.io/account/rdfbookmarks/ - which could then be shared as a 'thing' (or "bookmark"), with specified ACLs if required (and other metadata, dublin core, etc.). 
> 
> In relation to app preferences; i think that's simply that people navigate to the app first; whether it's on the same ldp or in a separate app / data space; with auth.  user then browses the graph to figure out what they want to edit and how. permissions controlled via rwwserver.
> 
> speaking of which; I think a nice little WAC interface is really important. All of these methods are dealing with external 'webid's' (whether FOAF, DOAP, SIOC, etc.) and the ability to manage permissions will likely provide significant support to defining the SPA solutions needed, to help developers more easily build social-apps.   
> 
> I've been thinking the next stages a bit; and i'm thinking it's a bit like the old days of 286's, where some clever stuff could be made in a bat file; given we're using ontological references, so long as we're using the same methods / language (rdf) we could have one app for permissions management, another for creating simple doap or foaf or whatever records,  etc. lifeshare circles seems to have started something useful (with interesting provenance);  the layoutit example seems to have enormous potential for helping people build websites, perhaps some 'widgets' (a bit like appinventor?) to help people assert RDF / Metadata, for dynamic content generation. 
> 
> At the moment, for the vast majority of people; it's bloody difficult to use one of these servers, and we probably just need some simple methods that test stuff out, and github it all. 
> 
> I think herein; the philosophical debate about WAC implementation models will be somewhat diverse; and perhaps rightfully so. creating instances may help 'graph' common methods, and perhaps based on the number of instances (usage graph data?), different models of WAC RDF methods can be explored.
> 
> haven't gone into IPv6/DNSSEC: assuming, server side, etc. 
> 
> hope that helps./timh.
> 
> On 02/01/2014, at 9:07 AM, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
> 
>> 
>> 
>> 
>> On 27 December 2013 22:15, Sébastien Lorber <sebastien@stample.co> wrote:
>> Hi all,
>> 
>> Hi & welcome to the group! :)
>>  
>> 
>> I'm working with Henry and I'm trying to build a Single Page Application (SPA) that can navigate to the RWW.
>> I can't find an elegant way to handle deep linking (possibility to bookmark/share the url) without reloading the whole page, which is not really a modern user experience.
>> 
>> 
>> 
>> Suppose I have an RDF resource located at http://sub.rwwserver.io/resource
>> 
>> The server actually detects that it's a browser with Accept prefering html content, so it sends some generic html page with some JS in it that will refetch the resource in RDF format, and startup the SinglePageApp to render that RDF graph.
>> 
>> This is a SinglePageApp so we aim to not refresh the page and reload the app as we navigate through the RDF graphs.
>> 
>> 
>> If this resource is a foaf profile:
>> http://sub.rwwserver.io/profile
>> Then on my SPA can eventually click on a friend of this foaf profile (foaf:knows) which will lead to a rendering the friend data, on which you can also click on one of its friends... 
>> 
>> When rendering a friend, as we are in a SPA, the url remain http://sub.rwwserver.io/profile
>> So if I want to bookmark or share the friend's page, I can't simply use the browser current url.
>> 
>> 
>> If the rendered friend is part of the subdomain, with HTML5 history pushState (or History.js) it is possible to modify the url and add an history element.
>> 
>> So if the first user to render is
>> http://sub.rwwserver.io/profile1
>> And then we render its friend
>> http://sub.rwwserver.io/profile2
>> it is possible to change the current url to profile2 url without reloading the page, even if the loaded page was profile1 url
>> 
>> But it's not possible to change the url without reloading if the url to set is on another domain or subdomain. This is a security issue because if you go to hacker.com, the site could change the url to yourbank.com and do some fishing more easily.
>> 
>> 
>> 
>> 
>> 
>> 
>> So what is the solution to build modern JS RDF applications (SPA) and be able to solve this deep linking problem?
>> 
>> 
>> We could probably change the url when the domain is the same, and redirect to the new resource to render when the domain is different. That wouldn't always redirect in many cases, particularly when the user navigate in its own content for exemple.
>> But when dealing with stuff like navigating in social networks and foaf profiles, it is very probable that the domain will often change between users...
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Js frameworks like Angular and Backbone usually use the url hash to perform routing and solve this deep linking problem.
>> 
>> So I may be able to use something like that:
>> http://sub.rwwserver.io/profile#currentResource=http://otherrww.io/otherprofile
>> This way the url becomes bookmarkable and shareable, but the problem is it's not really the true resource url that you share, and that many urls of this kind (with hash) could point to the same resource url:
>> http://sub.rwwserver.io/someContent#currentResource=http://otherrww.io/otherprofile
>> http://test.rwwserver.io/#currentResource=http://otherrww.io/otherprofileThis kind of defeat the original goal of an url I guess.
>> 
>> And if the first url is not available anymore, the link won't work, even if the targeted resource is still available...
>> 
>> 
>> 
>> In addition, in my opinion, an user should be able to "choose" the application he wants to open an RDF resource, as we can currently do in OS: you can open .doc files with Word or OpenOffice, and have a default prefered app. So many SPA could be used to render the same foaf profile.
>> 
>> If I choose app1 to render a profile, app1 may create a #currentResource=url . and then I can send the link to someone.
>> But this other person may prefer to renderprofiles with app2, and maybe app2 is not able to understand the hash semantics used by app1 for deep linking, so it will render the original profile and not the profile in #currentResource=url
>> 
>> This could eventually become a hacky standard for building RWW SPA, to use the same hash semantics.
>> But another problem is ACL. If I share a link originalResource#currentResource=url
>> then i have myself access to originalResource, but the other user may not have access so the server won't load any SPA even if that other user have access to the targeted resource
>> 
>> It could perhaps be done at the RWW server level (not sure, the url hash is sent?) so that the server automatically redirect the client to the targeted resource (without checking ACLs on the original) if it detects the #currentResource=url fragment
>> But this doesn't solve:
>> - the RWW server could be down
>> - the url is ugly
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Do you see any solution to this problem?
>> 
>> 
>> One solution could be to have some kind of equivalent of:
>> Access-Control-Allow-Origin: *
>> lke 
>> Access-Control-Allow-History-PushState: *
>> implemented on browsers and added on RWW server responses, but it wouldn't really prevent fishing because hacker.com could change the url to http://rwwserver.io/myBankAccount and show credit card forms...
>> Maybe this can be used only on non-sensitive RDF resource url
>> 
>> What do you think?
>> 
>> Very interesting use case, thanks for raising it.  We have the same issue in tabulator.
>> 
>> I wonder if the ideal solution would be something like when the browser asks you for your location.
>> 
>> There could be a popup saying:
>> 
>> "This site wishes to change the value in your address bar"
>> 
>> - Allow once
>> - Always allow
>>  
>> The issue might be then that the value in the address bar may not match the actual content, so perhaps a little signal could appear next to the address to show that it is not definitive.
>> 
>> Do you think that would work?
>> 
>> PS Regarding using the # character, whatever is after the hash should never been seen by the server, but you can use a ? like in:
>> 
>> http://graphite.ecs.soton.ac.uk/browser/?uri=http%3A%2F%2Fmelvincarvalho.com%2F
>> 
>> 
>> 
>> 
>> Thanks
>> 
>> 
>> 
>> 
> 
>