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

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/otherprofileThiskind 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
>>
>>
>>
>>
>
>