Web Payments Community Group Telecon

Minutes for 2012-04-03

Agenda
http://lists.w3.org/Archives/Public/public-webpayments/2012Apr/0000.html
Topics
  1. Commerce Vocabulary Properties
  2. Credit Card Vocabulary
  3. PaySwarm Vocabulary
Chair
Manu Sporny
Scribe
undefined
Present
Manu Sporny, David I. Lehn, Dave Longley
Audio Log
Manu Sporny: we're continuing to go through the vocabularies today. we'll get to the pay vocab and see if we need it. [scribe assist by Dave Longley]

Topic: Commerce Vocabulary Properties

Manu Sporny: we left off last time on the payeePosition property. [scribe assist by Dave Longley]
Manu Sporny: we were thinking we might get rid of payeePosition, in preference for the use of JSON-LD @list feature. [scribe assist by Dave Longley]
Manu Sporny: we're postponing that decision until JSON-LD progresses a bit. next up is the payment gateway. [scribe assist by Dave Longley]
David I. Lehn: as i say every week, let's link to the latest specs.
Manu Sporny: it might belong in the pay vocab for credit cards, bank accounts, etc. [scribe assist by Dave Longley]
Dave Longley: Yeah, I think we're mostly in agreemen that we need to move it out into another "payments" vocabulary. [scribe assist by Manu Sporny]
Manu Sporny: ok, then we'll move it out. [scribe assist by Dave Longley]
Dave Longley: This belongs in the commerce vocabulary [scribe assist by Manu Sporny]
Manu Sporny: Agreed, moving on. [scribe assist by Manu Sporny]
Manu Sporny: Is this a payment vocabulary thing, or a commerce vocabulary thing? [scribe assist by Manu Sporny]
Dave Longley: I think this is a commerce thing - not a payment thing. [scribe assist by Manu Sporny]
Dave Longley: Seems like this belongs in the commerce vocabulary. [scribe assist by Manu Sporny]
Manu Sporny: i'm a bit split, i can see it going in either. [scribe assist by Dave Longley]
Manu Sporny: but i'm ok with keeping it in the commerce vocab since there are good arguments either way. [scribe assist by Dave Longley]
Manu Sporny: last are source and transfer, source is a source account for a commercial transaction and transfer being the most fundamental unit of monetary transfer. [scribe assist by Dave Longley]
Manu Sporny: a transfer is the movement of money ... multiple transfers are contained in a transaction. [scribe assist by Dave Longley]
Manu Sporny: both of those are commerce terms. [scribe assist by Dave Longley]
Manu Sporny: we need to discuss the pay vocab in a little more depth as to what it actually does. [scribe assist by Dave Longley]
Dave Longley: nothing else to add to the commerce vocabulary discussion. [scribe assist by Manu Sporny]
Manu Sporny: ok moving on [scribe assist by Manu Sporny]
Dave Longley: i think we covered most of what we needed in the last discussion [scribe assist by Dave Longley]

Topic: Credit Card Vocabulary

Manu Sporny: cc vocab is a way to describe credit cards and debit cards and using them to process payments and put money into an account on a payswarm authority. [scribe assist by Dave Longley]
Manu Sporny: (this is how it related to payswarm) [scribe assist by Dave Longley]
Manu Sporny: the result of a charge is that money is pulled out of a credit card and put into a storage account online. [scribe assist by Dave Longley]
Manu Sporny: we need to add a bank/banking source. [scribe assist by Dave Longley]
Dave Longley: Yeah, we currently have that in our source code - we started to create a 'bank' prefix - we may not need to make as much as a distinction on credit card vs. debit card. It's not necessary as it relates to how you process credit cards / debit cards. [scribe assist by Manu Sporny]
Dave Longley: We do need stuff like routing numbers, bank account numbers. [scribe assist by Manu Sporny]
Dave Longley: we'll need rounting, bank account numbers, etc. [scribe assist by Dave Longley]
Manu Sporny: so we'll need to take what's in the cc vocab and add it to a new vocab like payment along with the bank information. [scribe assist by Dave Longley]
Manu Sporny: we probably just want "card" instead of credit card. [scribe assist by Dave Longley]
Dave Longley: Yes, we want to make this as general as possible. We have "cards", that can have brands ("Visa", "Mastercard", "Best Buy Gift Card", etc.) [scribe assist by Manu Sporny]
Manu Sporny: it seems like a bank account could just be a sub class of com:Account [scribe assist by Dave Longley]
Dave Longley: Yeah, we could do that. If we want to re-use "Account", we may want to differentiate it as "BankAccount" instead of attempting to duck-type it. [scribe assist by Manu Sporny]
Manu Sporny: what are we calling the new vocab? [scribe assist by Dave Longley]
Dave Longley: probably just "pay" with a prefix of "pay" [scribe assist by Dave Longley]
Manu Sporny: going down to the properties, we have brand...it's a text string like "visa", etc. [scribe assist by Dave Longley]
Manu Sporny: that's fine, we have expiration dates, years, verification code, etc, all things associated with cards. [scribe assist by Dave Longley]
Dave Longley: We don't use 'name' anymore - we use vcard stuff for it now... [scribe assist by Manu Sporny]
David I. Lehn: i have question about expiration dates... [scribe assist by Dave Longley]
David I. Lehn: do we want to use some kind of xsd year/month type for those properties so we can use semweb tech? [scribe assist by Dave Longley]
Dave Longley: We don't want to make this too complicated - not combine "expirationMonth" and "expirtaitonYear" to "expiration" [scribe assist by Manu Sporny]
Dave Longley: We want a good balance. [scribe assist by Manu Sporny]
Manu Sporny: if we're using JSON-LD we could just use the number 11 in JSON, etc. [scribe assist by Dave Longley]
Dave Longley: We want to use numbers in the JSON, and put the year/month typing into the @context. [scribe assist by Manu Sporny]
Dave Longley: if we could just mark this up in the JSON-LD context and use numbers in the JSON that would be best [scribe assist by Dave Longley]
Manu Sporny: we'll just do that for now, try and make that work. [scribe assist by Dave Longley]
Manu Sporny: name and address have been replaced by the vcard vocab. [scribe assist by Dave Longley]
Manu Sporny: there are lots of payment services that we would want to be able to mark up too [scribe assist by Dave Longley]
David I. Lehn: each one is a bit different [scribe assist by Dave Longley]
Manu Sporny: there's dwolla, paypal, etc. no generalized solution for this, so we should wait until these thigns are supported [scribe assist by Dave Longley]
David I. Lehn: i think that's ok, but in a general case, we need to figure out how to use this before we try and make it work [scribe assist by Dave Longley]
David I. Lehn: how do we handle cash? [scribe assist by Dave Longley]
Manu Sporny: that's outside of the system and your handling deposits which puts you into bank territory [scribe assist by Dave Longley]
Manu Sporny: if we're talking about a pay vocab then cash is a mechanism [scribe assist by Dave Longley]
David I. Lehn: we're going a little too far, we should leave it openended enough to handle it in the future [scribe assist by Dave Longley]
Manu Sporny: is there anything else to discuss? [scribe assist by Dave Longley]
Dave Longley: we're good. [scribe assist by Dave Longley]
Manu Sporny: there's another question about the pay vocab... [scribe assist by Dave Longley]
Manu Sporny: is there any overlap with opentransact? [scribe assist by Dave Longley]

Topic: PaySwarm Vocabulary

Dave Longley: there's some overlap with email addresses to/from and possibly paypal, etc. [scribe assist by Dave Longley]
Manu Sporny: for the classes we have asset, contract, data is something we don't use [scribe assist by Dave Longley]
Manu Sporny: data is a type of asset, people will want to use it so we should keep it [scribe assist by Dave Longley]
Manu Sporny: we have license, etc. we need these things. [scribe assist by Dave Longley]
Manu Sporny: webpage is a bit weird ... maybe we want an assets vocabulary [scribe assist by Dave Longley]
Dave Longley: I'd rather we consolidate rather than split vocabularies... we could put "pay" into commerce vocabulary. [scribe assist by Manu Sporny]
David I. Lehn: Once we have everything defined, it's not that big of a deal to move them together. [scribe assist by Manu Sporny]
David I. Lehn: it's probably worth thinking about that. .. once we define everything it isn't that hard to put them together. [scribe assist by Dave Longley]
Dave Longley: The purpose of data was being able to buy and sell bits of information in a P2P system (paying for data streams) [scribe assist by Manu Sporny]
David I. Lehn: the webpage term has a content url that is the same as the data one... what's the difference? [scribe assist by Dave Longley]
David I. Lehn: what's the difference in meaning? [scribe assist by Dave Longley]
David I. Lehn: could it all be collapsed into a resource or something because it's the same? [scribe assist by Dave Longley]
Manu Sporny: i don't think there's an obvious answer to your question because we haven't done that much with data at the moment. [scribe assist by Dave Longley]
Manu Sporny: we could have byte ranges or other things specified to talk about data [scribe assist by Dave Longley]
Manu Sporny: you could specify a file, etc. we just don't have a byte range example [scribe assist by Dave Longley]
Dave Longley: the meaning might be subtly different because when you buy data it might be a small chunk of data, not the whol efile [scribe assist by Dave Longley]
Dave Longley: you might also buy the data in different formats so the content URL refers to a song ... but the data could be purchased as mp3 or ogg, etc. [scribe assist by Dave Longley]
Manu Sporny: we could have separate classes for this that would better clarify this or the property meaning [scribe assist by Dave Longley]
Manu Sporny: we might just break this up into sections to make the vocab a little clearer [scribe assist by Dave Longley]
Dave Longley: it's sort of a way to add in layers like david nicol mentioned on the previous call [scribe assist by Dave Longley]
David I. Lehn: we might have a better generalized way to approach all this so i think we need more experience [scribe assist by Dave Longley]
Dave Longley: i think doign the layers is a good idea to try organizing this data and see if it works well instead of having to split vocabs up so much. [scribe assist by Dave Longley]
Manu Sporny: this describes any type of product you can think of, we could possibly reuse this. [scribe assist by Dave Longley]
Dave Longley: We could make it the general case that the PaySwarm Authority doesn't need to know the specific type of asset sold. The only concern is whether or not there are any rules that need to be applied based on the type of asset sold. [scribe assist by Manu Sporny]
Manu Sporny: we could just always import those other terms in from another vocabulary [scribe assist by Dave Longley]
Manu Sporny: maybe if we're doing crowd funding ... there is an example of asset that needs to be processed differently [scribe assist by Dave Longley]
Dave Longley: For example, for data, we may need to apply some rules that would need the code to do something different. [scribe assist by Manu Sporny]
David I. Lehn: i agree that the processing rules need to be things that are standardized and that we understand... [scribe assist by Dave Longley]
David I. Lehn: there may be extensions, etc., but this shouldn't be free form [scribe assist by Dave Longley]
Manu Sporny: we could get rid of webpage now if we're not using it to affect processing [scribe assist by Dave Longley]
Manu Sporny: and we tell people to use another vocab to mark things up how they want to be more descriptive [scribe assist by Dave Longley]
Dave Longley: Yeah, that's fine - remove them for now. Would be better to give people fewer options in the beginning. [scribe assist by Manu Sporny]
Dave Longley: especially if these things are specifically there to change the processing rules. [scribe assist by Dave Longley]
Manu Sporny: the next thing that's up is the no additional payees rule. [scribe assist by Dave Longley]
Manu Sporny: the reason that this exists is so that we can specify, in a listing (selling an article, etc), that they don't want any additional people adding fees to the item that they are selling [scribe assist by Dave Longley]
Manu Sporny: so we definitely need that and it's not a general commerce thing it's specific to payswarm which is why it's here. [scribe assist by Dave Longley]
Manu Sporny: we definitely need that, assets are in contracts, receipts, they are what's for sale. [scribe assist by Dave Longley]
Manu Sporny: next is assetAcquirer [scribe assist by Dave Longley]
David I. Lehn: yes, we use it [scribe assist by Dave Longley]
Dave Longley: yes, i believe so [scribe assist by Dave Longley]
Manu Sporny: assetProvider ... do we need that? [scribe assist by Dave Longley]
Dave Longley: yes [scribe assist by Dave Longley]
Manu Sporny: do we need authority? [scribe assist by Dave Longley]
Manu Sporny: can't we get that from the asset provider? [scribe assist by Dave Longley]
David I. Lehn: that isn't necessarily true, i didn't think those were bound together [scribe assist by Dave Longley]
Dave Longley: it might be used to specify the ID in the client config [scribe assist by Dave Longley]
David I. Lehn: i think we should do that a different way [scribe assist by Dave Longley]
Manu Sporny: there might be an argument to push a .well-known linked data services thing that can be served up in JSON-LD [scribe assist by Dave Longley]
David I. Lehn: i think how it's being used now is confusing, pointing it at a config URL [scribe assist by Dave Longley]
Dave Longley: We may still need ps:authority - we could use it in the service discovery stage to specify which authority IRI to trust when receiving signatures from it. [scribe assist by Manu Sporny]
Dave Longley: it specifies the owner for all keys to be trusted. [scribe assist by Dave Longley]
Dave Longley: the spec might need to be updated to cover that use. [scribe assist by Dave Longley]
Dave Longley: There are two different URLs - there is a distinction between where the asset is vs. where the information about the asset is. [scribe assist by Manu Sporny]
Dave Longley: the asset URL and the asset information URL may be different because the asset itself can't have the markup in it due to data format limitations. [scribe assist by Dave Longley]
David I. Lehn: The @id has the information about the asset, the contentUrl has the location of the data. [scribe assist by Manu Sporny]
Manu Sporny: are we using these URLs? [scribe assist by Dave Longley]
Manu Sporny: We need to determine if we're using this, right? [scribe assist by Manu Sporny]
David I. Lehn: it's a required feature [scribe assist by Dave Longley]
David I. Lehn: we might be able to avoid this now for webpages, but we'll immediately have a need for it [scribe assist by Dave Longley]
David I. Lehn: for any raw data stream that can't have embedded asset information in it [scribe assist by Dave Longley]
David I. Lehn: if you're buying something that doesn't have content, you don't need this property, like buying radio spectrum ... there is no content. [scribe assist by Dave Longley]
Manu Sporny: should we use content URL or just content. [scribe assist by Dave Longley]
David I. Lehn: i think we had a reason to do it at some point ... [scribe assist by Dave Longley]
Manu Sporny: maybe we wanted to be explicit to say they had to put a URL there, but we don't need to do that. [scribe assist by Dave Longley]
Manu Sporny: it makes it look ugly and we have plenty of other URL properties where we don't have that, it isn't a design pattern that is supported or useful. [scribe assist by Dave Longley]
Manu Sporny: let's drop it. [scribe assist by Dave Longley]
Dave Longley: we should drop URL, but we might change it to assetContent or something more explicit [scribe assist by Dave Longley]
David I. Lehn: why do we need "asset" there?" [scribe assist by Dave Longley]
Dave Longley: you can move properties around outside of an asset, there might be some confusion if it isn't general enough [scribe assist by Dave Longley]
Manu Sporny: maybe we should use something from dublin core? [scribe assist by Dave Longley]
David I. Lehn: do we need to support more structure/data formats, etc? [scribe assist by Dave Longley]
Manu Sporny: we could allow base64-encoding content instead of it being a URL, etc. [scribe assist by Dave Longley]
David I. Lehn: it seems like it might be a case that comes up with buying ebook formats, etc. various different formats. [scribe assist by Dave Longley]
David I. Lehn: it may be that the people are providing it may take you to a link outside of the contract with more information [scribe assist by Dave Longley]
Manu Sporny: dc:source doesn't really fit since it refers to the source material, i dont' see anything in dublin core that really fits. [scribe assist by Dave Longley]
Manu Sporny: let's just use content for now. [scribe assist by Dave Longley]
Dave Longley: Is there a situation where ps:content would be ambiguous? [scribe assist by Manu Sporny]
Manu Sporny: someone could use it in a way that's confusing, but i think in payswarm we're being very specific about its meaning [scribe assist by Dave Longley]
Manu Sporny: ok, we're at the top of the hour, we'll finish up the payswarm vocab [scribe assist by Dave Longley]
Manu Sporny: and get the documents updated. [scribe assist by Dave Longley]

Created by the Web Payments Community Group. Shared with love under a CC-BY license.