- From: Sébastien Lorber <sebastien@stample.co>
- Date: Sun, 12 Jan 2014 21:32:37 +0100
- To: Tim Holborn <timothy.holborn@gmail.com>
- Cc: Melvin Carvalho <melvincarvalho@gmail.com>, public-rww <public-rww@w3.org>
- Message-ID: <CAFyaO_mrsPHMGJc=WWwuD1W1ULGFXo8aSK9EMyzXFRo2oj8S8w@mail.gmail.com>
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 >> >> >> >> > >
Received on Sunday, 12 January 2014 20:33:06 UTC