the terms for to and from

[Melvin Carvalho]

I've been looking at the terms "to" and "from" wrt a transfer in webcredits / opentransact / payswarm and pingback ongologies

Payswarm uses

source
destination

Opentransact uses

to
from

Pingback uses

source
target

There's a slight complexity in that pingback has a "to" field to which is your pingback service.  So there's possible collisions of named query variables a theoretical possibility.

Of these 3 I think that "to" and "from" are the most intuitive, due to similarity to email / sms etc.

I'm considering changing web credits to use these fields. 

Any thoughts?

[Pelle Braendgaard]

I've always argued it is more intuitive and follows other similar email standards, which is why we use it in OpenTransact.

I think the PaySwarm community expressed some openness to change to that at some point.

P

--
http://picomoney.com - A whole new kind of money

http://payglo.be - Blog about payments from a global perspective

[Pelle Braendgaard]

via would be the one to use if it's necessary. 

I personally can't see the need for it though in a TCP/IP world where everything is in theory directly connected. 

That said I don't understand all the web credits use cases.

P

On Thu, Nov 29, 2012 at 12:19 PM, Andrew Miller <ami...@cs.ucf.edu> wrote:

Is there a "via"

--
Andrew Miller

[Manu Sporny]

On 11/29/12 11:17, Melvin Carvalho wrote:
> I've been looking at the terms 'to' and 'from' wrt a transfer in
> webcredits / opentransact / payswarm and pingback ongologies
>
> Payswarm uses
>
> source destination

Note that since PaySwarm uses JSON-LD, the developer can change this to
anything that they want to. You can just as easily do this:

{
'id': 'http://bluebank.com/transactions/329873',
'source': 'http://payswarm.example.com/accounts/blue',
'destination': 'http://redbank.com/accounts/red',
'amount': '50.43',
'currency': 'USD'
}

as this:

{
'id': 'http://bluebank.com/transactions/329873',
'from': 'http://payswarm.example.com/accounts/blue',
'to': 'http://redbank.com/accounts/red',
'amount': '50.43',
'currency': 'USD',
}

You just need to declare this context for the first example:

'@context': {
'@id': 'id', // alias @id to id
'source': {
'@id': 'http://purl.org/commerce#source',
'@type': '@id' // source is an IRI
},
'destination': {
'@id': 'http://purl.org/commerce#destination',
'@type': '@id' // destination is an IRI
},
...
}

and this context for the second one:

'@context': {
'from': {
'@id': 'http://purl.org/commerce#source',
'@type': '@id' // from is an IRI
},
'to': {
'@id': 'http://purl.org/commerce#destination',
'@type': '@id' // to is an IRI
},
...
}

Ultimately, it's up to the developers to pick what they'd like... a
PaySwarm service consuming an object like the above could accept either.
As for preference, I personally don't have any strong feelings one way
or the other. Pelle's argument about it being similar to e-mail is the
argument that is resonating the most with me regarding changing it in
the spec. My concern is that it's too generic and some people might be
annoyed that we've squatted on something as generic as 'to' and 'from'
and that they'd want to use those keywords in their application.
However, the same argument could be made for 'source' and 'destination'.

One compromise would be allowing 'source', 'destination', 'to', and
'from' in the PaySwarm JSON-LD context. That would allow the developer
to use whatever they wanted to use... but then, it would be a failure to
standardize on something. :P

-- manu

--
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: HTML5 and RDFa 1.1
http://manu.sporny.org/2012/html5-and-rdfa/

[David Nicol]

http://en.wikipedia.org/wiki/Substitute_check uses "payor" and "payee" the first time the concepts appear

http://www.gpo.gov/fdsys/pkg/BILLS-108hr1474enr/pdf/BILLS-108hr1474enr.pdf the Check 21 act uses "drawer" and "payee"

the 1996 tipjar.com give form use(d) "from" and "recipient"

--
One day, Mrs. Taylor told me that she used to have another kid, but that he had apparently fallen down one of the holes. Her description was very abstract. She said: “Well one day I saw him out there and I was watching and then I didn’t see him out there no more.”

[Melvin Carvalho]

Thanks Manu, yes there is the a lot of flexibility when you use @context.

Using the 'to' and 'from' would be to make things more intuitive in the examples.  For example

- naming fields in JSON
- naming fields in an HTML form
- naming fields in an API (e.g. like OpenTransact)
- naming fields in a relational database

I also like the email analogy.  Ie I can send you an email, and 'attach' a payment and also I could use exactly the same system to send a web style email.  As you say there's the risk of collision too ... so tricky
 

[Melvin Carvalho]

On 29 November 2012 18:46, Pelle Braendgaard <pe...@stakeventures.com> wrote:

via would be the one to use if it's necessary. 

I personally can't see the need for it though in a TCP/IP world where everything is in theory directly connected. 

That said I don't understand all the web credits use cases.

Hi Pelle.  Yes, I've had a bit of feedback along these lines.  What I am going to do is write up some user stories.

The main idea of webcredits is a clean modular separation of concerns.  You might think of a full payment system to be like a car, whereas webcredits is the engine.  However there are circumstances where webcredits can be used as standalone, for example, if you are dealing with trusted parties. 

One thing we've learnt working with identity over the years, is that a clean separation of components can fit together to make a system.  So for example authentication can be handled in a number of ways and a good standardization should allow you to swap in and swap out the ones you need.  So in the case of OpenTransact it could be OAuth for authentication and the OpenTransact for the API.  

IMHO, part of standardization should try and achieve a few high level functional engineering goals ... e.g. loose coupling, non collision of APIs, clean modular design.  In this way we can take different parts that people work on and reuse them in particular use cases and workflows.

Does that make a bit more sense?
 

[Melvin Carvalho]

On 30 November 2012 04:33, David Nicol <david...@gmail.com> wrote:

http://en.wikipedia.org/wiki/Substitute_check uses "payor" and "payee" the first time the concepts appear

http://www.gpo.gov/fdsys/pkg/BILLS-108hr1474enr/pdf/BILLS-108hr1474enr.pdf the Check 21 act uses "drawer" and "payee"

the 1996 tipjar.com give form use(d) "from" and "recipient"

Matt Slater uses payer and payee in his Drupal table.  I thought about this, then decided to align with payswarm since the documentation was already written.