Text archives Help


Re: [projectvrm] Concepts | Apache Unomi


Chronological Thread 
  • From: Devon Loffreto < >
  • To: Adrian Gropper < >
  • Cc: Guy Jarvis < >, ProjectVRM list < >
  • Subject: Re: [projectvrm] Concepts | Apache Unomi
  • Date: Wed, 7 Feb 2018 10:13:20 -0500

Is that a real question or are you being humorous? Its going as you might expect. Compliance is a social norm. Individual liberty is not, at mass scale.

I have a team walking factory floors across China currently. One is returning home after 5 years in US. Immediate reaction to seeing role of WeChat domination was startling. From city to deep rural, cash is disappearing. Social structure drives operational results.

People seek convenience. Individual liberty is never easy. Compliance is always easy, until its not. State planning in China is a force w/o limit, and alternative models are breaking w/ ease b/c "easy" wins mass-adoption.

Credit.. still optional.

Devon


On Feb 7, 2018 9:50 AM, "Adrian Gropper" < "> > wrote:
The experiment Guy describes is already being run in China with social credit scoring. Does anyone have an update on how that's going?

Adrian

On Tue, Feb 6, 2018 at 4:51 PM, Guy Jarvis < " target="_blank"> > wrote:
At a conceptual level, what instantly occurred to me was "udontnomi"
which might be achieved through a couple of different pathways.

The first perhaps more obvious route is to (attempt to) block unomi
from gathering any personal data, the main drawback that comes to mind
is that blocking may prevent access to a desired resource

The second route is to appear to willingly accept unomi then poison it
with junk data to render unomi worthless.

In the latter case, I guess the programmatical challenge is
client-side browser coding to fool the server-side unomi, plus some
means of p2p sharing junk between clients.

Guy


On Tue, Feb 6, 2018 at 6:56 PM, Tom Barnett < " target="_blank"> > wrote:
> http://unomi.incubator.apache.org/versions/1.2/concepts.html
>
> I wondered if anyone had any views on this?
>
> '
>
> Profiles
>
> By processing events, Unomi progressively builds a picture of who the user
> is and how they behave. This knowledge is embedded in Profile object. A
> profile is an Item with any number of properties and optional segments and
> scores. Unomi provides default properties to cover common data (name, last
> name, age, email, etc.) as well as default segments to categorize users.
> Unomi users are, however, free and even encouraged to create additional
> properties and segments to better suit their needs.
>
> Contrary to other Unomi items, profiles are not part of a scope since we
> want to be able to track the associated user across applications. For this
> reason, data collected for a given profile in a specific scope is still
> available to any scoped item that accesses the profile information.
>
> It is interesting to note that there is not necessarily a one to one mapping
> between users and profiles as users can be captured across applications and
> different observation contexts. As identifying information might not be
> available in all contexts in which data is collected, resolving profiles to
> a single physical user can become complex because physical users are not
> observed directly. Rather, their portrait is progressively patched together
> and made clearer as Unomi captures more and more traces of their actions.
> Unomi will merge related profiles as soon as collected data permits positive
> association between distinct profiles, usually as a result of the user
> performing some identifying action in a context where the user hadn’t
> already been positively identified.'
>
>



--

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.




Archive powered by MHonArc 2.6.19.