October 4, 2009

Micros in Federation

As previously noted, Micros is the microblogging running inside Melative, and one of the major goals is cross-domain compatibility and fluidity; aka Federation. Rather than build something similar to OpenMicroBlogging protocol, we decided to design a specification protocol which the microblog will use to solve this problem of cross-domain following. (Just for reference, any publishing software can use the specification, it’s open and being fleshed)

Here, I’d like to address 4 aspects of the service to help enrich the understanding of this Federated specification, as well as the solution and benefits it provides.

What problem does Federated micro-publishing solve?

  • Social services may only be used with valid usership
  • Social relations may not be established without mutual usership (centralization)
  • Social services are closed, by nature (one must have an account)
  • Social services are centralized (e.g. thedomain.com)
  • Users are following other rules (e.g. site agreements)
  • There is no freedom, as there are always requirements (e.g. usership)

How is this a unique solution?

  • Decentralized (users on any domain may be part of the social-sphere)
  • Federated (users may establish relations without regard for central usership)
  • It’s a specification
  • It’s an open protocol
  • It’s adaptable and customizable

We are only implementing a version of what is possible through the API specification. Other developers may create their own platforms which will interact in the same fashion. The aim with Micros is a publishing platform, similar to a blog, but extensible through theming and plugins. The core of Micros will be a hooking environment in which 3rd party scripts may execute.

Is there evidence that this works?

What sort of business model does it cater?

  • No central ownership
  • Specification provides an infinite platform
  • Open development
  • 3rd party applications
  • 3rd party features
  • Potentially massive user-base (the Internet)

The importance in the business model is that the specification allows developers/vendors to create their own pay/private services, which still enables interaction with the social-sphere. Also open is the area of customizations, similar to Wordpress’s flourishing theme/plugin base.

In summary, we are modularizing the microblog to fit this specification in hopes of building a larger, open social publishing network that may be used regardless of usership and domain.

April 11, 2009

Context-Designated MicroBlogging

Context-designated microblogging, as described here, is generally a superset of the OpenMicroBlogging specification. The notion comes from the concept of contexts which are microblogged about.

Assumptions

We assume the non-grammatical understanding of the word, context, and point towards the notion of context within a computer system or application. In this light, context will represent the topic or target of a user’s notice or an event stemming from a user action. For our purposes context, topic, and target may be used interchangeably (terminology is adjustable, but the idea stands as topic/target/context sensitive/aware/designated microblogging).

Read the rest of this entry »

December 14, 2008

Technical Example: Ratings

I took a short bit of time to conduct an experiment comparing ratings of a standard 10-point system to the result which would occur on melative.

Here is a the whitesheet and a second model (though lacking proper detail).

The most disappointing part of this example is that assumptions were required in order for the system to work. Firstly, it is assumed that every user has exactly 10 levels, as compared to the real-implementation where users have lists varying in size. Secondly, it is assumed that every user has exactly 10 experiences, and more precisely, one experience per level. This forces a uniform distribution in the relative computation of the calculation. In short, all users have equal rating power, which is only true in this ideal system, or in systems which are not relative.

Compared to the linear and weighted model of the source data, the relative model produces a more modest grade; 7.02 and 7.71 (melative) vs 8.3 and 8.23. For this example, the melative rrs can be considered a heavy weighting, but this is only when relating to a 10.0 scale. Within melative, the two highlighted areas, point-based and pertecnt-based, offer insight to the rating, especially when comparing to another item in the system.

Point-Based

The point-based value yields an absolute value, or total awarded grade across the system. This is special in that there is no cap on the value, and each item in the system is graded equally when it appears on a list. Since the specific grade/rating depends on the system state, we will consider this value to be an energy; for any snapshot of the system, there is a total amount of energy, and each item contributes. If a this value is rather large, it is good indication of popularity, though not soley in event instances or activity. Rather, this value expresses both solid viewership and grading.

From this value, it is also necessary to create a derived value based on points/total number of appearances. A point-average disregards popularity, and expresses an item’s average grading spread solely on experienced users. The point-average is important, but it is based on a subset of the users, and in that way, it is similar to the percent-based value.

Percent-Based

If the point-value was an energy, the percent-value will be considered a potential. Similar to the point-average, the percent-value is a percentage of potential; how high an item appears on lists system-wide. This value is also based on the point-value, but rather than dividing by a head count, we divide by the maximum points that were available; the current state when item appears on a list.

Statistically, a 100% potential would require every appearance of an item to be alone in the top tier/level. Potential can be related more to a 10.0 scale, weighted, non-relative system, though the innerworkings are entirely different from the basis of calculation.

Looking closely at the example, percent-value and point-average appear to be exactly the same, but this comes with the assumptions of the test (10-levels for each user). In the case of point-average, the maximum number of points is disregarded, and when there is power variation between users, the point-average will yield a differing value to the percent-value.

Well, it was fun, and for reference we will be using the second model as it degrades more smoothly. A linear degrade is optional, but for now we stress that higher items are more significant.