Marc's Voice

 Wednesday, February 25, 2004
Monkey Protein Blocks HIV

macaque
 
For years, AIDS researchers have struggled with the lack of a good animal model of HIV infection. The ideal candidates, Old World monkeys such as rhesus macaques, are not susceptible to HIV, although they are vulnerable to the monkey version of the virus, known as simian immunodeficiency virus (SIV). Scientists have suspected for some time that monkeys respond to HIV by producing a factor that stops the virus in its tracks. Now they have pinpointed this natural HIV blocker.

In a paper published today in the journal Nature, Joseph Sodroski and his colleagues at Harvard University identify this factor as a protein called TRIM5-alpha. Preventing TRIM5-alpha activity in monkey cells made infection with HIV possible, the researchers report, whereas adding the protein to human cells prevented HIV from taking holdThe protein may function by inhibiting the virus’s ability to shed its protective coating, which must be removed before the virus can replicate.

Here's Matt Mower's thoughts on adding ESF events to the When category of the k-collector.

I'm gonna rely upon Matt and Paolo to grok all this stuff. I just hope they're making sure:

  • that all these events standards can work together
  • that they've gone back and checked out the earlier standardization efforts that happened in the blogosphere (I seem to remember an rdf schema from Danny Ayers)
  • that they're talking to Andrew Baio of UpComing.org.

Schedule and Calendar aggregation is key to the overall digital lifestyle aggregation scenario.

ESF, topics and K-Collector.

Event Sharing, publishing, syndicating, etc. When we introduced the "when" part in the w4 concept, almost one year ago, what we had in mind was a space where events would be topics which could be aggregated in calendars and allowed users to navigate information using a timeline.
...
Using the same approach we are using with topics, new events will be automatically distributed among members of a cloud allowing users to pick an event if it already exist instead of creating it.

There will also be relations between events and other topics on the server, which we believe will create a sigificant added value to the process (allowing, for example, to quickly move to all information related to an event to all information related to one of the participants).

[Paolo Valdemarin: Paolo's Weblog]

The When classification was always a key part of the overall vision of K-Collector. Being able to navigate sensibly based upon time & date is a very powerful concept.

One of the last things I did within liveTopics before moving on to K-Collector was to implement time as an XFML facet. This created a hierarchy of topics representing dates. For example there was a topic "2003". This in turn contained 12 sub-topics "Jan 2003" through "Dec 2003". Each of these topics contained a further division by date. Posts were linked to these topics based upon publication date. The upshot was that you could browse based on an increasingly specific date filter.

We will be looking to implement When topics in K-Collector in conjunction with ESF events. The idea will be to link the event (perhaps defined as a What topic), with a particular point in time (a When topic), a place (Where) and possibly people attending (Who). Hence an event will form a glue which binds together a number of different topics in a context.

Example:

What
blogtalk 2.0
Where
Vienna
Who
Thomas Burg
When
5-Jul-2004

There are still issues to work out like: What about events which span multiple days? Do we represent time on the calendar? What about recurring events? And so on. But I think even a simple model which dodges many of these questions would be amply useful at this point.

[Curiouser and curiouser!]

When he heard about the liquidation sale of MP3.com assets, Michael Robertson clarified some issues (via the pho list.)

While I was the CEO, MP3.com never purchased a Hummer or a Harley. I've never driven a Harley or a Hummer. And if there's an oxygen bar in the auction, that ain't from MP3.com either.

I think those items are from other companies Vivendi purchased.

-- MR

Marc Barrot has been busy....

Introducing the enhancedAggregator.

aggregator topicsI've recently spent some time investigating Radio's aggregator code, looking for an easy way to support additional RSS modules in general, and ENT 1.0 topics in particular.

The enhancedAggregator tool is the -provisional- result of this investigation. It comes with full ENT 1.0 topics support for Radio's aggregator, and skeletons for aggregating Atom 0.3 feeds and ESF 1.0 events for RSS 2.0.

I'd like the enhancedAggregator to become a community driven project, allowing Frontier/Radio developers to easily test aggregation of new syndication formats and extensions, without mobilizing Userland scarse resources.

So I've added some intial/uninstall/update/prefs ancillary functions to the tool, and provided guidelines for updating the current drivers and adding new ones, with pointers to the available online documentation.

I hope Matt will copy the ENT module driver and paste it into the k-collector client for Radio, and Paolo's eVector crew will build upon the ESF module driver skeleton, copying the result to their new tool when it's stable enough.

[s l a m]

Pieces of the pie

Marc Eisenstadt left this comment (in regards to multiple levels of relationships in social networking):

I know you're not claiming (merely) that '7 levels' is better than '2', i.e. there's plenty more that you're saying or implying (and have said in the past) about the context and semantics of these relationships... HOWEVER, I'm wondering if you could bear to spell it out some more. Say, a "Dummies Guide to Relationship Semantics" or something along those lines! This is NOT about FOAF-parsing and RDF, for which there are already many dummies guides out there... this is an extremely hairy and profound issue, and I have yet to see any social networking system that even remotely captures *ANY* elements of my online or realworld networking relationships. Help!

Marc Eisenstadt [m.eisenstadt@open.ac.uk] • 2/24/04; 6:58:19 PM
 
OK Marc (I love that guy's name!) - here's my answer to your request:
 
A Dummies Guide to Relationship levels
 
Yes - multiple levels of relationships are better than 2.  100 would be better than 7, but I guess you gotta look at it from this POV - what do you DO with these levels?  Is there anything expressed in the system which allows/denies you access/communciation/etc. - based upon the specific level established between 2 people?
 
First things first - in our PeopleAggregator system, you can't establish a 'Close Friend' or 'Friend' relationship without email verification - while the 'other' kinds of relationships (Acqauintance, Know by reputation, Know in passing, Don't know, but wanna know) are more one-sided and don't requoire any verification.  You have the option of automatically reciprocating the Friend invite or (in the case of blood relatives) you're automatically reciprocated - if indeed you ARE a relative.
 
In Flickr - there is an implied path - starting with 'Acquaintance' - which can then evolve to a 'Friend' - if you wish to.
 
The AlwaysOn Network - supports the notion of comrade, vendor, prospect, customer, etc. - so there are a few systems which are going beyiond just friend (1) or not (0).
 
Now I'm certainly not saying that these approaches are perfect (gotta watch out - danah is ready EVERY word I say!) - but it's sure as hell better than JUST friend or not.  I could go off on how tehse levels can be extended by end-users - but I won't - right now.
 
In the system we're working on now (which can't tell you about in more detail till May) we're playing with enabling folks to do different things - based upon what level of relationship they've established.
 
Other system could use these levels as a form of reputation - but that's for another Dummie's guide....
 
Let's just leave it at this: all Dummies need to know is that they don't HAVE to choose between being a friend or not.   There are simple techniques available for slicing up the relationship pie into infinitesimal pieces. 
 
But it's what you DO with these levels of relationships that count.   But it's a kind of a catch-22. Unless you slice up the pie into pieces, all you'll have is one giant round pie- and nobody's got a big enough mouth to eat all that - not even me!

TiVo-like devices to get booster shot. Tomorrow's digital video recorders will be able to record two live shows and shuttle recorded content to several TVs at once, setting up a battle with PC makers. [CNET News.com - Personal Technology]

Record 2 shows while streaming out 4.

'Bout time!

This is really interesting.....

mythbusting orkut. according to actioncontents:

yesterday at the hotel bar in the infamous etech lobby i learned from a credible insider source, that orkut was by no means programmed by orkut in his "extra project time", but that google had 40 people for 4 months working on it full time. the cheesy design and the orkut folklore is just a cover-up, in order to make it appear low-key.
40 sounds a bit much, but i suspect somewhere between there and the "one guy in his spare engineering time" story peddled by google, lay the truth. [lineofsight - photography, information technology, surfing, art, blogs, etc]