Gold and other Asset Classes in OWP

4 views
Skip to first unread message

Andreas Pizsa

unread,
Jul 22, 2010, 4:05:04 AM7/22/10
to Open Web Payments
Hi Praveen,
great initiatve, thanks for putting your time and thoughts into it.
I've posted a short intro of OWP to the agile-banking group to help
spread the word :)

http://groups.google.com/group/agile-banking/t/ce2213e832066a3c

One thing I noticed and would like to discuss is the "funding type"
attribute, especially in regards to "alternative" asset classes such
as Gold, other metals or securities.

I would suggest to change the currency attribute in OWP:amount to
"assetClass" and use a standard asset class identifier as the value.

The advantage would be that the OWP could support any and all asset
classes and can therefore be adopted by other players as well, such as
GoldMoney and others.

Feedback and ideas welcome :)

--A.

Praveen Alavilli

unread,
Jul 22, 2010, 10:08:06 AM7/22/10
to owp...@googlegroups.com
Hi Andreas,

Thank you and thanks for joining the group and spreading the word out to the agile-banking group too.


If you look in the second example in the slides (Digital goods app - using Pre-Pay), we tried to incorporate other assets into the fundingType and currency attribute :-)

<OWP:funding-type>http://owp-api.net/schema/1.0/funding-types/Gold</OWP:funding-type>

<OWP:amount currency=”bar">2</OWP:amount>


Yes it did not sound like a natural fit but that's the best we could come up with for now, which is simple and easy to understand. We thought other names like "assetClass" were a little more abstract and some times could be confusing for a developer on what values to use there. 

When I hear about AssetClass all I think about are investment related things like securities/equities, bonds, commodities, real-estate, etc. including cash.  So it does makes sense to be more generic but I am wondering if we lose the simplicity. Any other thoughts ?

cheers,
Praveen

Pelle Braendgaard

unread,
Jul 22, 2010, 11:00:31 AM7/22/10
to owp...@googlegroups.com, agile-banking
Hi Praveen,
I hope the talk went well and I'm glad you've managed to put a full
stack together here.

Just posted my initial reactions to OWP here:

http://stakeventures.com/articles/2010/07/22/open-web-payments-paypals-answer-to-opentransact

It may come across overly critical, but I think the biggest problem I
have with OWP so far is the lack of a currency URI. The actual URI
that you post your message to should determine which type of
payment/currency it is.

I mention in the post that I think this comes from the tradition that
payments are messages. But using this funding-type element for me is a
very bad idea. It introduces a bunch of complexities that shouldn't be
in the payment itself.

Andreas has a good proposal on asset class identifiers
http://groups.google.com/group/agile-banking/browse_thread/thread/2df4fe6d946899c5?hl=en
that could be used in the discovery process.

I am pasting in some text from my post about this particular issue:

The web on the other hand works using the concept of resources and
actions. It is pretty object oriented in this way. Messaging
applications can be created on top of the web, but the complexities
are hidden behind this object oriented world. This is how atom,
twitter, facebook etc all work.

The best example of a field all payment messaging standards require is
the currency field. On the web we don't need this as we have URI's.

A payment is the transfer of one resource to another. So lets model
that in the restful object oriented way. Each currency has a separate
URI:

* http://paypal.com/owp/usd
* http://paypal.com/owp/eur
* http://goldpal.eg/aug

HTTP POST to this URI to transfer funds. HTTP GET to get transactions
in that currency.

In addition in the above grocery transaction the funding types
elements. Neither the merchant nor the consumer cares about these.
They are also extremely specific to PayPal and are likely not of any
interest to most other people wanting to implement this, such as
banks. They could be modeled into the URIs as well:

* http://paypal.com/owp/usd - do whatever default behavior is
* http://paypal.com/owp/usd/creditcard
* http://paypal.com/owp/usd/checking

These options could be presented to merchant using WebFinger.

P

--
http://agree2.com - Reach Agreement!
http://stakeventures.com - My blog about startups and agile banking

Ray Tanaka

unread,
Jul 23, 2010, 12:18:47 AM7/23/10
to Open Web Payments

Hey everyone -

The concept of representing currency as it relates to an entity makes
total sense to me. It's a great way to avoid naming collisions and
support unlimited currencies - both real and virtual. I still need to
think about URN vs URL. Both are compelling to me for different
reasons.

Funding type seems to make sense too but this, too, is something I
need to noodle on a bit.

I'll discuss this a bit with Praveen the next chance I get and one of
us shall follow up.

And if things seem PayPal-centric, that's a result of us being
influenced by what we know. I think we can all agree that this
proposal is useless if it only works for PayPal.

- Ray

On Jul 22, 8:00 am, Pelle Braendgaard <pe...@stakeventures.com> wrote:
> Hi Praveen,
> I hope the talk went well and I'm glad you've managed to put a full
> stack together here.
>
> Just posted my initial reactions to OWP here:
>
> http://stakeventures.com/articles/2010/07/22/open-web-payments-paypal...
>
> It may come across overly critical, but I think the biggest problem I
> have with OWP so far is the lack of a currency URI. The actual URI
> that you post your message to should determine which type of
> payment/currency it is.
>
> I mention in the post that I think this comes from the tradition that
> payments are messages. But using this funding-type element for me is a
> very bad idea. It introduces a bunch of complexities that shouldn't be
> in the payment itself.
>
> Andreas has a good  proposal on asset class identifiershttp://groups.google.com/group/agile-banking/browse_thread/thread/2df...
> that could be used in the discovery process.
>
> I am pasting in some text from my post about this particular issue:
>
> The web on the other hand works using the concept of resources and
> actions. It is pretty object oriented in this way. Messaging
> applications can be created on top of the web, but the complexities
> are hidden behind this object oriented world. This is how atom,
> twitter, facebook etc all work.
>
> The best example of a field all payment messaging standards require is
> the currency field. On the web we don't need this as we have URI's.
>
> A payment is the transfer of one resource to another. So lets model
> that in the restful object oriented way. Each currency has a separate
> URI:
>
> *http://paypal.com/owp/usd
> *http://paypal.com/owp/eur
> *http://goldpal.eg/aug
>
> HTTP POST to this URI to transfer funds. HTTP GET to get transactions
> in that currency.
>
> In addition in the above grocery transaction the funding types
> elements. Neither the merchant nor the consumer cares about these.
> They are also extremely specific to PayPal and are likely not of any
> interest to most other people wanting to implement this, such as
> banks. They could be modeled into the URIs as well:
>
> *http://paypal.com/owp/usd- do whatever default behavior is
> *http://paypal.com/owp/usd/creditcard
> *http://paypal.com/owp/usd/checking
>
> These options could be presented to merchant using WebFinger.
>
> P
>
>
>
> On Thu, Jul 22, 2010 at 10:08 AM, Praveen Alavilli <ppalavi...@gmail.com> wrote:
> > Hi Andreas,
>
> > Thank you and thanks for joining the group and spreading the word out to the
> > agile-banking group too.
>
> > If you look in the second example in the slides (Digital goods app - using
> > Pre-Pay), we tried to incorporate other assets into the fundingType and
> > currency attribute :-)
>
> > <OWP:funding-type>http://owp-api.net/schema/1.0/funding-types/Gold</OWP:funding-type>
>
> > <OWP:amount currency=”bar">2</OWP:amount>
>
> > Yes it did not sound like a natural fit but that's the best we could come up
> > with for now, which is simple and easy to understand. We thought other names
> > like "assetClass" were a little more abstract and some times could be
> > confusing for a developer on what values to use there.
>
> > When I hear about AssetClass all I think about are investment related things
> > like securities/equities, bonds, commodities, real-estate, etc. including
> > cash.  So it does makes sense to be more generic but I am wondering if we
> > lose the simplicity. Any other thoughts ?
>
> > cheers,
> > Praveen
>
> > On Thu, Jul 22, 2010 at 1:05 AM, Andreas Pizsa <hops...@gmail.com> wrote:
>
> >> Hi Praveen,
> >>  great initiatve, thanks for putting your time and thoughts into it.
> >> I've posted a short intro of OWP to the agile-banking group to help
> >> spread the word :)
>
> >>http://groups.google.com/group/agile-banking/t/ce2213e832066a3c
>
> >> One thing I noticed and would like to discuss is the "funding type"
> >> attribute, especially in regards to "alternative" asset classes such
> >> as Gold, other metals or securities.
>
> >> I would suggest to change the currency attribute in OWP:amount to
> >> "assetClass" and use a standard asset class identifier as the value.
>
> >> The advantage would be that the OWP could support any and all asset
> >> classes and can therefore be adopted by other players as well, such as
> >> GoldMoney and others.
>
> >> Feedback and ideas welcome :)
>
> >> --A.
>
> --http://agree2.com- Reach Agreement!http://stakeventures.com- My blog about startups and agile banking

Melvin Carvalho

unread,
Jul 23, 2010, 12:41:30 AM7/23/10
to owp...@googlegroups.com, marti...@ebusiness-unibw.org
On 23 July 2010 06:18, Ray Tanaka <rta...@gmail.com> wrote:

Hey everyone -

The concept of representing currency as it relates to an entity makes
total sense to me. It's a great way to avoid naming collisions and
support unlimited currencies - both real and virtual. I still need to
think about URN vs URL. Both are compelling to me for different
reasons.

Funding type seems to make sense too but this, too, is something I
need to noodle on a bit.

I'll discuss this a bit with Praveen the next chance I get and one of
us shall follow up.

And if things seem PayPal-centric, that's a result of us being
influenced by what we know. I think we can all agree that this
proposal is useless if it only works for PayPal.

Note that the following term is already widely deployed (bestbuy, yahoo etc.):

http://www.heppnetz.de/ontologies/goodrelations/v1#hasCurrency

The currency for all prices in the Price Specification given using the ISO 4217 standard (3 characters).

There is perhaps an argument to express a currency as a URL too?

Andreas Pizsa

unread,
Jul 23, 2010, 9:36:06 AM7/23/10
to Open Web Payments
> There is perhaps an argument to express a currency as a URL too?

Yup; we're exploring these at

http://groups.google.com/group/agile-banking/browse_thread/thread/2df4fe6d946899c5?hl=en

Best,A.

On Jul 23, 6:41 am, Melvin Carvalho <melvincarva...@gmail.com> wrote:
> On 23 July 2010 06:18, Ray Tanaka <rtan...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Hey everyone -
>
> > The concept of representing currency as it relates to an entity makes
> > total sense to me. It's a great way to avoid naming collisions and
> > support unlimited currencies - both real and virtual. I still need to
> > think about URN vs URL. Both are compelling to me for different
> > reasons.
>
> > Funding type seems to make sense too but this, too, is something I
> > need to noodle on a bit.
>
> > I'll discuss this a bit with Praveen the next chance I get and one of
> > us shall follow up.
>
> > And if things seem PayPal-centric, that's a result of us being
> > influenced by what we know. I think we can all agree that this
> > proposal is useless if it only works for PayPal.
>
> Note that the following term is already widely deployed (bestbuy, yahoo
> etc.):
>
> http://www.heppnetz.de/ontologies/goodrelations/v1#hasCurrency
>
> *The currency for all prices in the Price Specification given using the ISO
> 4217 standard (3 characters).*
> > > *http://paypal.com/owp/usd-do whatever default behavior is
> > > --http://agree2.com-Reach Agreement!http://stakeventures.com-My blog

Praveen Alavilli

unread,
Jul 25, 2010, 3:43:57 PM7/25/10
to owp...@googlegroups.com
I like the URNs mainly when the values are based on an ISO standard for the reasons you've mentioned in the email below. But how would a virtual currency work in this case ? There is not going to be a standard for them (at least in the near future) - so wondering if it makes sense to represent them as URNs too or as URIs.  But again as you said, the virtual currency providers could always provide ways to discover more information about them through other means.

Regarding the Funding Types, merchants, API caller/consumer (platform/application/developer) and some times even the end users, do care about them based on the use case. In case of financing (loans) use cases, neither the loan givers nor takers must be allowed to pay with a credit or yet another loan or speaking of a bank's use case not with a line of credit for example. This is nothing specific to PayPal except for the fact that we learned about these use cases from a few developers using PayPal Platform.  That said - I do agree the name "FundingType" is confusing - may be we need to generalize it more. This is some what close to the gr:PaymentMethod but more closely related to the Assets itself than payment providers. (gr:PaymentMethod seems to be including both)

Btw - thanks Melvin for the pointer to GoodRelations - definitely a good model to follow and learn from, and thanks Martin for your insights on this topic.

Going back to the original suggestion on renaming "currency" attribute in OWP:amount as "assetClass" - looking at ISO 4217, which also uses the term "currency" for things other than cash,  I am still wondering what's the right name to use. Also is "currency" good enough ? For example in case of "Gold" (XAU), specifying the amount as 2 means what ? 2 Kg or 2lb or 2g etc. Does this only apply to metals ? 

<OWP:amount currency=”urn:x-asset:iso4217:XAU">2</OWP:amount>



cheers,
Praveen
Reply all
Reply to author
Forward
0 new messages