OpenJournal
This is a rough design (BlueSky) for a Semantic Web application. It may be useful from both ends, in showing how the current technologies might be deployed and perhaps in seeing how they fall short in letting us easily build this kind of system. It's pretty skeychy still. It mostly boils down to: add a bunch of other RDF data to your RSS feeds.
The idea here is to build a LiveJournal clone which would be fully distributed and open, using appropriate web technologies.
Related notes elsewhere: the DataSources page in the FOAF wiki lists some sites for which FOAF RDF/XML views are (directly or indirectly) available.
This is naive in that it is NOT based on a thorough study of either LJ technology or deployed RSS technologies which may already address some of these issues. This is a Killer App for SandroHawke because a huge fraction of his (non-work) social group uses LJ, and it would be nice to rescue them from the beast (as benevolent as it might be).
This fits somewhere in with NewMediaConvergence, RDFApplicationsAndProjects, and SeedApplications. And the whole Pie/Echo/... RSS re-thinking thinking. This is like SemanticMud in being a rough design for a distibuted system matching an existing monolithic system. There may be design patterns to be drawn out of the combination.
- Friends. LJ lets you publish your friends list and see whose
friends lists you are in. FOAF can do this, within the limits of spidering and how you define friend.
- Controlled access to postings. Many LJ postings are friends-only.
This could be done by leveraging off the friends list above and one of several kinds of authorization. For instance, my "friends-only" posting might simply be encrypted using a key which is published encrypted using the public keys of each of my friends -- obtained by FOAF spidering. (There are attacks here based on website defacing, which can be contolled with a sufficiently thorough cross-signing effort. LJ itself generally requires what amounts to cross signing, in that to use it you must get a secret code from another user or use your credit card.
Without Public Key Crypto, one could just do a challenge-response with secrets. Basically, I would grant access to some content to whoever can affect the content at certain URIs (my friends' home pages).
- Of course there are the servers. The way to handle this is to
let a thousand servers bloom. You can get your own hosting account for under $20/mo and share it with dozens, even hundreds of people you know. You could tie access to your friends-list.
- But even better would be replication. Oooooeee. That would be
sweet. But the current web can't do that, can it now. If I give my identity as http://www.w3.org/People/Sandro/basics#sandro, and (improbably as it may sound) the w3.org servers are down, you're not going to be able to find my postings, see my friends list, see my public key, etc, etc.
Ohhhhhhh, sure it can. Yes, you COULD try HTTP to that URI to get information about me, but there's nothing stopping you from asking around your friends about me either! You might not want to flood the whole net with a query about me, but in an LJ-style app, it's likely that you'd be one or at most two hops from some mutual friends' servers which happened to have lots of data about me. Data like where my information is replicated..... This just might work.
Of course something like freenet would be nice too, etc, etc. Whatever.
But I'm imagining you use your UI of choice and if you ask it to find out about Joe, it'll try Joe's URI, but if that fails it'll do a mild (depth=2?) spider of your friends to see who knows what about Joe. You might want to do that anyway, actually.
This whole design is predicated on each "user" having a web presence, an always-on agent acting on their behalf (ie some web space) but that seems completely reasonable.
- LJ has some features of integrating with Pagers and IM. It's
not clear what's needed there other than some FOAF data.
There are some heavy URI issues here. People need to be identified by GoodURIs, as do messages/postings of all sorts. But where do you draw the line between identifying the posting itself (eg in naming permissions to it and replies to it) and identifying a web page which displays the posting and perhaps some of the threads it's involved in...??????? Oh, and identifying servers where information about the posting might happen to be replicated.
Suggestion:
- GET on posting (or person) URI returns HTML page
about the posting and its replies, etc, with RDF information about how to get RDF information about it. (Maybe use content negotation, in addition to embedding.) Also have an RDF icon so people can easily click to end up with the RDF data.
- How to resolve this against needing to talk about
that information source? Do we need to? If so, use HashURI or SlashURI I guess!
FHKT OwNz U fhkt@linuxmail.org Protect ur wiki protected? now? take 3
Congratulations; you peed on the sidewalk. Anybody can do that, but most of us don't. We think it's gross, and we'd like to keep the sidewalk available for more productive use. Yes, we could disable anonymous writes (see AboutThisService), but we'd rather not.
Ok if you are going to make a livejournal clone, you could import all your friends user data from LJs rss feeds in the format of http://www.livejournal.com/users/username/data/rss. I wouldnt import more than your friends data though as the whole livejournal database is massive. With Ljfind I am currently trying this but It looks like the hosting cost will be massive for terrabytes of data (thousands and thousands of dollars a month).