- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Fri, 25 May 2012 23:56:04 -0400
- To: Web Payments <public-webpayments@w3.org>
On 05/14/2012 06:11 PM, Michiel de Jong wrote: > The webcredits spec was meant to be expanded, and i am now at a > point where it is not expressive enough for opentabs. Also I think > its variable naming could be improved using Hungarian prefixes like > the ones I posted to the rww cg list on Saturday. We had a very long discussion about these types of microsyntaxes in the early days of the JSON-LD work, and then again during the early stages of the PaySwarm work. In both cases, multiple people, both inside and outside of the various communities that we were presenting the work to suggested very strongly that microsyntaxes are anti-developer. After years of working on this stuff, we (DB) come to the position that Hungarian notation, and micro-syntaxes in general are bad design for Linked Data. The best documentation of what should be supplied to a Linked Data property should be in the application or vocabulary documentation. > So here is a draft version of the concepts i am currently thinking > of introducing for Opentabs. > > https://github.com/unhosted/website/wiki/opentabs-data-format Some high-level feedback for now: The concept of a 'deal' looks very close to something that becomes a contract after the verbal agreement in PaySwarm, which is a Contract: http://purl.org/payswarm#Contract Also, keep in mind that verbal contracts are contracts in the eyes of most legal systems. So, you need to be very careful with terminology here as your Deals could easily become legally enforceable documents. That is, the data fields make them more than what you purport them to be in the documentation - they are legally enforce-able contracts. 'transfers' Why didn't you just re-use: http://purl.org/commerce#transfer If the definition needs to change, let's do that instead of there being two 'transfer' terms for these vocabularies. 'implicit transfers' This sounds like a bad idea... a level of abstraction that is only being created because of the state of financial systems today. Just because you note that money is moving back and forth doesn't mean you need to physically move the money. Better to have the full transaction and monetary flow instead of unnecessarily breaking transfers into two different types. 'Balances' Why can't you just query the account to get the current balance. If necessary, you could have a different field 'settledAmount' vs. 'availableAmount' vs. 'amount'. 'Agreements' This seems to either overlap with a Contract or a License or both. It's kinda vague what an Agreement is supposed to accomplish from a legal standpoint and what differentiates it from a deal. Have you thought about how these pieces of data would be used in a court of law? -- manu -- Manu Sporny (skype: msporny, twitter: manusporny) Founder/CEO - Digital Bazaar, Inc. blog: PaySwarm Website for Developers Launched http://digitalbazaar.com/2012/02/22/new-payswarm-alpha/
Received on Saturday, 26 May 2012 03:56:37 UTC