Re: Directories of Projects to Webize

I think we need to create an ‘evangelism' or advocacy group, perhaps coordinated via the ‘webize’ initiative.   Generally, there’s developers already working on many of these projects; the problem is they’re not really aware of rww or how to use it.  So, i few can set methods / principles - then share and support app owners (who in-turn maintain their products) we might improve our ‘viral’ approach, in getting more apps. ‘webized’.

i’d imagine we’ll need some sort of conformance outline…

i use linux as a good example; there’s a few base-flavours, then a bunch of branded packages, with version control, etc. 

I can see the need for parsers for images, creating .meta files - therein querying rww not based on file-names but rather .meta info (which could organically develop) but in other cases; it’s very much like github… 

I think melvin was setting-up a list of candidates? 

I’ve been working on figuring out a better communications method - ideally one that uses a rww server.  the epub3 method is aimed at provides a way to collaborate on documentation then publish in a version controlled / exportable fashion. 

anyhow; set-up #webize on irc.freenode.net 


On 30 Jan 2014, at 9:47 am, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

> 
> 
> 
> On 29 January 2014 23:39, Tim Holborn <timothy.holborn@gmail.com> wrote:
> Reading http://www.w3.org/DesignIssues/Webize.html it says 'ACL'd r/w linked data’
> 
> kif is cool.
> 
> so; quick chat to stample, discuss https://github.com/stample/react-foaf - that we need a method to ‘make’ for multiple platforms, perhaps create github branches?  
> 
> meanwhile; getting frustrated with comm’s method (as an example), so looking at what’s up with epub3…
> 
> find http://aloha-editor.org/blog/2013/06/browser-based-epub3-ebook-editor-powered-by-github-aloha-editor/ with a splash of http://oerpub.github.io/github-bookeditor/  - https://github.com/mediaprophet/epub.js and https://github.com/hypothesis ( http://hypothes.is/ ), thinking shuttle worth is doing some v.cool work, i keep stumbling across their projects…  
> 
> The idea that GitHub is just one big rww platform is a kinda interesting view, that seems to be used for some reason by the book editor project… 
> 
> Webizing git / github would be extremely cool.  Perhaps the easiest way to do this is via  gitlab:
> 
> http://gitlab.org/
>  
> 
> so; then thinking about how ‘fun’ it is to go find some app that exists somewhere, then load it up and link it to my data.fm or rww.io or rww-play or open link instance; it’s just not that ‘chrome extensions’ experience so many like to use, to just show how cool, how simple, how awesome this rww stuff is.
> 
> yeah, read-write-web is part of the game, but we’ve got a few names and the ‘platform’ type of thing, doesn’t seem to sing ‘linux’ no-matter the flavour (stample/rww.io/openlink/data.fm, - thinking data.fm / rww.io are both kinda like ‘debian’ based systems - just rww styles). Having an app that’s 5 star linked data - might cut it, but it doesn’t really cut into the WebID/RWW/LDP lifecycle specifically (often better when messing with JS based apps, rather than older complex LAMP systems, mind both work…)
> 
> in all areas of life all people are lay-people at something…  http://en.wikipedia.org/wiki/Luddite has a good story to it; but i’m a believer in knowledge systems, looks like we’re coming to a milestone of a rather significant journey…
> 
> On 30 Jan 2014, at 1:10 am, carmen <_@whats-your.name> wrote:
> 
>> "We do need a name we can stick to. ;)"
>> 
>> Semantic-Web <- sounds too AI, unrealistic until machine-learning deployed widely at client-level?
>> Linked-Data <- referring to serializations & data-model not entire platform
>> Read-Write-Web <- is this not the current name?
>> 
>> you can read+write to just about any website though, save for luddite geocities-freaks who are still serving files via Apache and writing to them only via FTP/Rsync/SCP,
>> 
>> but you'll need to reverse-engineer large mounds of obfuscated&minized JS with FireBug/WebkitDevtools or mitmproxy+tshark, and emulate their usage of ad-hoc site-specific APIs, over and over ..
>> 
>> thus, borrowing nomenclature from Complex Math, these solutions which while "on the web" are not "on the read-write web" since the "web" part of the name implies a shared/unified way of doing writes, and related offshoots like identity + auth(orize|enticate)
>> 
>> IRWW . Imaginary Read-Write Web . just link your "app" to liboursitedata.jar and you can read+write. we swear it's a "website" (the URL is https://api.liboursite.com) even though only accessible w/ SPDY, not HTTP 0 and only outputs JSON, not HTML, and uses our homebrew auth system. this ensures the smoothest user-experience, as determined by highly-paid UI consultants
>> RRWW . Real Read-Write Web . stample/ldphp/other-newcomers
>> 
>> so it's no longer the triple-W, but the double-RW - WWW RW + POSIX+RW underneath in most cases, unless you're a hyper anti-luddite who exclusively use RAM-only blobstores having abolished the filesystem to antiquity
>> 
> 
>