Questions about interoperability versus simply using a URI in a record
1 view
Skip to first unread message
els
Mar 23, 2009, 6:17:23 AM3/23/09
to prowl-users
From http://newcurrencyfrontiers.blogspot.com/2009/03/metacurrency-grammars-and-twollars.html
"Metacurrency grammars and Twollars
In the metacurrency world, one of the key things we need is a grammar
to that allows us to specify what a transaction will look like for a
particular currency. Yesterday Art & I had a wonderful conversation
with Eiso and Mac from Twollars about how this might be accomplished
in a mult-currency Twollars universe. Twollars is based on parsing
tweets from the public timeline looking for a particular format that
indicates that the tweet is supposed to be a transaction. Here's an
example tweet that Twollars recognizes:
Give @artbrock 2 Twollars because he's brilliant
Grammatically this translates to:
Give [subject] [quantity] Twollars because [reason]
Twollars could become deeply multi-currency if instead of there being
just that one hard-coded grammar, anybody could specify a grammar for
the Twollars server to recognize as a transaction for their currency.
All that's needed is to throw in a hash tag to specify the currency.
Here's an example:
Twollars: #zippybucks Give @artbrock 2 because he's brilliant.
The meta-grammar here that the Twollars server could parse is:
Twollars: #[currency-name] [transaction]
And then the [transaction] part gets parsed by the currency specific
grammar which is:
Give [subject] [quantity] because [reason]
Now there's one other thing that has to be added for this to work, and
that is a notion of what state a transaction is transforming. I.e.
what's the aggregate result of many transactions. In the case of the
current Twollars, the state is the balances of tweeter and the
tweetee, and the transformation rules are simple:
1) Tweetee balance is incremented by [quantity]
2) Tweeter balance is decremented by [quantity]
But this too should be up for grabs and specifiable by the currency
creator. The way Twollars has started out, users are issued 50
Twollars to begin with. This means that the total amount of thanks
that can circulate in the system is 50 times the number of users.
Think about it. Does that really make sense? Not really because my
capacity to be grateful and acknowledge value given to me isn't hard
limited like that, which is not to say that it's infinite. Eiso and
Mac have very good reasons for starting out Twollars as they did, so
I'm not knocking that at all. I'm just pointing to the fact that in
the multi-currency world we want communities to be able to specify the
circulation properties of the currency as suites them best. So, lets
imagine a different "thanks" currency where you can "give" different
words of gratitude (or ingratitude for that matter) and instead of a
balance in that currency, what you have is a count of those words
given and received. Here are some sample transactions:
Twollars: #thx Thanks @zippy314 for his amazing...
Twollars: #thx Appreciates @fer_ananda for her....
Twollars: #thx Scolds @artbrock for ..
Now when specifying such a currency we need to give both it's grammar:
#thx = [action:Thanks,Scolds,Appreciates] [@] for [description:what]
and define what the states are, which for this currency are simply 6
numbers, the count of thanks/scolds/appreciates given and received,
and also give the transformation rules which are just:
1) Tweeter [action word given count] increased by 1
2) Tweetee [action word recieved count] increased by 1
Of course the Twollars interface should hide almost all of the
underlying details of the states and transformation rules, by giving
us a simple AJAXy way of defining our little transaction grammars and
choosing various state transform options, and it would all be really
easy, fun and cool. From the sounds of it, you might see something
like this on Twollars no too far in the future…
Here are some more examples of other such currencies that Art & I came
up with:
A simple LETS currency:
#lets = [action:Pay] [@] $[qty:int] for [description:what]
State transform: qty adjusts Balances
Example:
Twollars: #lets Pay @artbrock $2 for currency consulting
A Kilowatt Hour currency:
#kwh = [action:Energize] [@] with [qty:int]kwh for [description:what]
State transform: qty adjusts Balance [where balance max = infinity &
balance min = 0]
Example:
Twollars: #kwh Energize @artbrock with 2kwh for currency consulting
A LOL Cat acknowledgement currency:
#lolcat = [action:can haz cheezburgr, cant haz cheezburgr] [@] forze
[description:stuff]
State transform: action adjusts Counts: e.g. 20 can haz. 0 cant haz
Example:
Twollars: #lolcat can haz cheezburgr @zippy314 forze cieling cat
prayrz
A currency for rating political debates:
#DebateVote = [action:rates] @obama [rating] stars @mccain [rating]
stars
State transform: rating adjusts Average
Example:
Twollars: #DebateVote rates @obama 4 start @mccain 1 stars
Posted by Eric Harris-Braun at 5:59 AM
7 comments:
marc tirel said...
Thanks.
Just a question/remark about tha grammar and counting words instead of
quantities.
In the #thx example you have 3 actions. 2 of them are very similar:
"thanks" & "appreciates". We could also imagine having "likes" and/or
"Loves" actions and let the currency creators decides of an
equivalence between those actions.
For instance 1 Love = 5 Likes
1 Love = 10 appreciates
1 thanks = 1 Appreciates
Does it make sense to you ?
March 19, 2009 7:32 AM
Gerry said...
Anything you can reliably parse out of the twitter stream can be a
currency. I'm thinking that we need a formal syntax for precisely
describing a currency play as well as being able to parse more natural
language ones from context. Already there could be confusion from
talking about twollers vs. plays in twollers.
I like something like $<currencyname>(@<recipiant>,<value>[,<value]*)
for xyz
The ideas is to have a currency symbol that works like the hash symbol
in hashtags and atsign for twitter identities.
The main point is that you have to be very careful in designing a
grammar or you will create more ambiguity and confusion. In the
metacurrency context, we need a grammar that can at least handle all
currency plays. Another twitter grammar for currency definitions might
be fun, but let's hold off on that part of the design.
March 19, 2009 7:39 AM
Gerry said...
You can add twollers to the system by buying t-shirts too, which I
think I might do soon.
But you point is well taken that they need to have more ways of
issuing currency.
Another point is that twitter space is a global space, so if other
groups are also creating currency syntax we had better make sure they
don't collide. Note that there are a number of GIS based sites that
tag with location too, and we can define plays in terms of location
too, so the expansive definition of currency takes in a lot.
March 19, 2009 7:44 AM
Eric Harris-Braun said...
Marc,
Yes it certainly makes sense in some contexts to have an sense of
relative difference between levels of a non-continuous valuation
scheme. But in other situations it might not make sense at all. Hence
the need for the multi-currency world!
-Eric
March 19, 2009 9:47 AM
Alan Rosenblith said...
This is fantastic! I hope we can get some momentum to implement this
soon. One thing to keep in mind: the grammar will have to be
practically transparent. Eiso and Mac tried to incorporate all
variations on the normal twollar transaction format. We will need
similar attention here.
Also we will need a no-brainer UI. I suggested to them "presets" as a
good starting point. For example: "time-bank" could be a currency
preset. Or for that matter, once twollars can handle multiple account
types: community way. I think getting mutual-credit going will be a
first key step in this process though.
March 19, 2009 10:44 AM
Edgar said...
Please let me know if this is too much info and I would be glad to
take my concerns elsewhere.
IMHO, interoperability means much more than just avoiding collisions.
To me, it also means minimizing the vocabulary that my parser and
someone else's parser have to know to process transaction records that
are generated by different systems.
E.g., if the transaction record formats are unique for each [currency
name], the parser code will have to accomodate all applicable grammar
separately.
It seems that #[currency-name] should be #[grammar-accounting
convention] instead, so that the grammar-accounting options for each
currency would be limited by a preset conventions that parsers would
have an easier time accomodating. This would also simplify currency
set-up for new currency admins. An example grammar-accounting
convention is something like Prowl, Twollars+mutual-credit or x12+GAAP
(abbreviated as needed). The convention being in front is similar to
having HTTP or FTP in front of a URI.
To simplify coding farther, each grammar convention should have few
verbs or keywords, and allow for noun or subject diversity in a
standard format. For example, I would prefer if the [subject] is
expressed as a domain name, so that my code could use plain HTTP to
find where I could cross-verify that the credit recipient (e.g.,
artbrock.com) has accepted a transaction record. This way, I don't
have to know a registry's IP address or program another step just to
find @art. Domain based names also guarantee uniqueness.
This requirement may be specific to my currency design, but if cross-
verification is not possible, there would be no auditability.
To specify a currency community, the field after the amount could be
combined as [currency-name+units], as in USdollars.
I realize these are all preliminary, but while some suggestions such
as using domain based names may seem clunky, my intent is to help
minimize coding and coordination.
But this is mostly just the publisher part, what about the possibility
of auditing the back end or ledger reconcilability? This is not just a
prowl concern, see http://copsewood.net/mrs/mrsspec.html#4.4. For
example, what if I wanted to graph and compare the periodic
performance of a currency that I am following?
March 20, 2009 4:24 PM
Edgar said...
Sorry, unlike Eric's exact examples, I got a little bit sloppy with my
example for #[grammar+accounting convention], which should have read:
#Prowl+ocaup
or
#Twollars+mutual-credit
or
#x12+GAAP
or
#Prowl+cc
And as a farther clarification, my concerns mostly stems from the
possibility that that subjects in a transaction may belong to
different entities, e.g., one is registered with twitter.com while the
other is registered with anotherentity.org, AND each entity maintains
its own ledger independently."
"Metacurrency grammars and Twollars
In the metacurrency world, one of the key things we need is a grammar
to that allows us to specify what a transaction will look like for a
particular currency. Yesterday Art & I had a wonderful conversation
with Eiso and Mac from Twollars about how this might be accomplished
in a mult-currency Twollars universe. Twollars is based on parsing
tweets from the public timeline looking for a particular format that
indicates that the tweet is supposed to be a transaction. Here's an
example tweet that Twollars recognizes:
Give @artbrock 2 Twollars because he's brilliant
Grammatically this translates to:
Give [subject] [quantity] Twollars because [reason]
Twollars could become deeply multi-currency if instead of there being
just that one hard-coded grammar, anybody could specify a grammar for
the Twollars server to recognize as a transaction for their currency.
All that's needed is to throw in a hash tag to specify the currency.
Here's an example:
Twollars: #zippybucks Give @artbrock 2 because he's brilliant.
The meta-grammar here that the Twollars server could parse is:
Twollars: #[currency-name] [transaction]
And then the [transaction] part gets parsed by the currency specific
grammar which is:
Give [subject] [quantity] because [reason]
Now there's one other thing that has to be added for this to work, and
that is a notion of what state a transaction is transforming. I.e.
what's the aggregate result of many transactions. In the case of the
current Twollars, the state is the balances of tweeter and the
tweetee, and the transformation rules are simple:
1) Tweetee balance is incremented by [quantity]
2) Tweeter balance is decremented by [quantity]
But this too should be up for grabs and specifiable by the currency
creator. The way Twollars has started out, users are issued 50
Twollars to begin with. This means that the total amount of thanks
that can circulate in the system is 50 times the number of users.
Think about it. Does that really make sense? Not really because my
capacity to be grateful and acknowledge value given to me isn't hard
limited like that, which is not to say that it's infinite. Eiso and
Mac have very good reasons for starting out Twollars as they did, so
I'm not knocking that at all. I'm just pointing to the fact that in
the multi-currency world we want communities to be able to specify the
circulation properties of the currency as suites them best. So, lets
imagine a different "thanks" currency where you can "give" different
words of gratitude (or ingratitude for that matter) and instead of a
balance in that currency, what you have is a count of those words
given and received. Here are some sample transactions:
Twollars: #thx Thanks @zippy314 for his amazing...
Twollars: #thx Appreciates @fer_ananda for her....
Twollars: #thx Scolds @artbrock for ..
Now when specifying such a currency we need to give both it's grammar:
#thx = [action:Thanks,Scolds,Appreciates] [@] for [description:what]
and define what the states are, which for this currency are simply 6
numbers, the count of thanks/scolds/appreciates given and received,
and also give the transformation rules which are just:
1) Tweeter [action word given count] increased by 1
2) Tweetee [action word recieved count] increased by 1
Of course the Twollars interface should hide almost all of the
underlying details of the states and transformation rules, by giving
us a simple AJAXy way of defining our little transaction grammars and
choosing various state transform options, and it would all be really
easy, fun and cool. From the sounds of it, you might see something
like this on Twollars no too far in the future…
Here are some more examples of other such currencies that Art & I came
up with:
A simple LETS currency:
#lets = [action:Pay] [@] $[qty:int] for [description:what]
State transform: qty adjusts Balances
Example:
Twollars: #lets Pay @artbrock $2 for currency consulting
A Kilowatt Hour currency:
#kwh = [action:Energize] [@] with [qty:int]kwh for [description:what]
State transform: qty adjusts Balance [where balance max = infinity &
balance min = 0]
Example:
Twollars: #kwh Energize @artbrock with 2kwh for currency consulting
A LOL Cat acknowledgement currency:
#lolcat = [action:can haz cheezburgr, cant haz cheezburgr] [@] forze
[description:stuff]
State transform: action adjusts Counts: e.g. 20 can haz. 0 cant haz
Example:
Twollars: #lolcat can haz cheezburgr @zippy314 forze cieling cat
prayrz
A currency for rating political debates:
#DebateVote = [action:rates] @obama [rating] stars @mccain [rating]
stars
State transform: rating adjusts Average
Example:
Twollars: #DebateVote rates @obama 4 start @mccain 1 stars
Posted by Eric Harris-Braun at 5:59 AM
7 comments:
marc tirel said...
Thanks.
Just a question/remark about tha grammar and counting words instead of
quantities.
In the #thx example you have 3 actions. 2 of them are very similar:
"thanks" & "appreciates". We could also imagine having "likes" and/or
"Loves" actions and let the currency creators decides of an
equivalence between those actions.
For instance 1 Love = 5 Likes
1 Love = 10 appreciates
1 thanks = 1 Appreciates
Does it make sense to you ?
March 19, 2009 7:32 AM
Gerry said...
Anything you can reliably parse out of the twitter stream can be a
currency. I'm thinking that we need a formal syntax for precisely
describing a currency play as well as being able to parse more natural
language ones from context. Already there could be confusion from
talking about twollers vs. plays in twollers.
I like something like $<currencyname>(@<recipiant>,<value>[,<value]*)
for xyz
The ideas is to have a currency symbol that works like the hash symbol
in hashtags and atsign for twitter identities.
The main point is that you have to be very careful in designing a
grammar or you will create more ambiguity and confusion. In the
metacurrency context, we need a grammar that can at least handle all
currency plays. Another twitter grammar for currency definitions might
be fun, but let's hold off on that part of the design.
March 19, 2009 7:39 AM
Gerry said...
You can add twollers to the system by buying t-shirts too, which I
think I might do soon.
But you point is well taken that they need to have more ways of
issuing currency.
Another point is that twitter space is a global space, so if other
groups are also creating currency syntax we had better make sure they
don't collide. Note that there are a number of GIS based sites that
tag with location too, and we can define plays in terms of location
too, so the expansive definition of currency takes in a lot.
March 19, 2009 7:44 AM
Eric Harris-Braun said...
Marc,
Yes it certainly makes sense in some contexts to have an sense of
relative difference between levels of a non-continuous valuation
scheme. But in other situations it might not make sense at all. Hence
the need for the multi-currency world!
-Eric
March 19, 2009 9:47 AM
Alan Rosenblith said...
This is fantastic! I hope we can get some momentum to implement this
soon. One thing to keep in mind: the grammar will have to be
practically transparent. Eiso and Mac tried to incorporate all
variations on the normal twollar transaction format. We will need
similar attention here.
Also we will need a no-brainer UI. I suggested to them "presets" as a
good starting point. For example: "time-bank" could be a currency
preset. Or for that matter, once twollars can handle multiple account
types: community way. I think getting mutual-credit going will be a
first key step in this process though.
March 19, 2009 10:44 AM
Edgar said...
Please let me know if this is too much info and I would be glad to
take my concerns elsewhere.
IMHO, interoperability means much more than just avoiding collisions.
To me, it also means minimizing the vocabulary that my parser and
someone else's parser have to know to process transaction records that
are generated by different systems.
E.g., if the transaction record formats are unique for each [currency
name], the parser code will have to accomodate all applicable grammar
separately.
It seems that #[currency-name] should be #[grammar-accounting
convention] instead, so that the grammar-accounting options for each
currency would be limited by a preset conventions that parsers would
have an easier time accomodating. This would also simplify currency
set-up for new currency admins. An example grammar-accounting
convention is something like Prowl, Twollars+mutual-credit or x12+GAAP
(abbreviated as needed). The convention being in front is similar to
having HTTP or FTP in front of a URI.
To simplify coding farther, each grammar convention should have few
verbs or keywords, and allow for noun or subject diversity in a
standard format. For example, I would prefer if the [subject] is
expressed as a domain name, so that my code could use plain HTTP to
find where I could cross-verify that the credit recipient (e.g.,
artbrock.com) has accepted a transaction record. This way, I don't
have to know a registry's IP address or program another step just to
find @art. Domain based names also guarantee uniqueness.
This requirement may be specific to my currency design, but if cross-
verification is not possible, there would be no auditability.
To specify a currency community, the field after the amount could be
combined as [currency-name+units], as in USdollars.
I realize these are all preliminary, but while some suggestions such
as using domain based names may seem clunky, my intent is to help
minimize coding and coordination.
But this is mostly just the publisher part, what about the possibility
of auditing the back end or ledger reconcilability? This is not just a
prowl concern, see http://copsewood.net/mrs/mrsspec.html#4.4. For
example, what if I wanted to graph and compare the periodic
performance of a currency that I am following?
March 20, 2009 4:24 PM
Edgar said...
Sorry, unlike Eric's exact examples, I got a little bit sloppy with my
example for #[grammar+accounting convention], which should have read:
#Prowl+ocaup
or
#Twollars+mutual-credit
or
#x12+GAAP
or
#Prowl+cc
And as a farther clarification, my concerns mostly stems from the
possibility that that subjects in a transaction may belong to
different entities, e.g., one is registered with twitter.com while the
other is registered with anotherentity.org, AND each entity maintains
its own ledger independently."
els
Mar 23, 2009, 11:47:21 AM3/23/09
to prowl-users
On Mar 23, 3:17 am, els <sioso...@hotmail.com> wrote:
> Fromhttp://newcurrencyfrontiers.blogspot.com/2009/03/metacurrency-grammar...
Reply all
Reply to author
Forward
0 new messages