From W3C Wiki
Jump to: navigation, search

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, and
  (improbably as it may sound) the 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.


  • 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 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 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).