Web Payments Telecon Minutes for 2012-04-03

Thanks to Dave Longley for scribing! The minutes for today's telecon are
available here:

http://payswarm.com/minutes/2012-04-03/

Full text of the discussion follows for archival purposes at the W3C.

---------------------------------------------------------------------
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
Facilitator:
   Manu Sporny
Scribe:
   Dave Longley
Present:
   Dave Longley, Manu Sporny, David I. Lehn
Audio:


Dave Longley is scribing.
Manu Sporny:  We're continuing to go through the vocabularies
   today. We'll get to the pay vocab and see if we need it.

Topic: Commerce Vocabulary Properties

Manu Sporny: http://payswarm.com/vocabs/commerce
Manu Sporny:  we left off last time on the payeePosition
   property.
Manu Sporny: http://payswarm.com/vocabs/commerce#payeePosition
Manu Sporny:  we were thinking we might get rid of payeePosition,
   in preference for the use of JSON-LD @list feature.
Manu Sporny: http://payswarm.com/vocabs/commerce#paymentGateway
Manu Sporny:  we're postponing that decision until JSON-LD
   progresses a bit. next up is the payment gateway.
David I. Lehn: as i say every week, let's link to the latest
   specs.
David I. Lehn: http://payswarm.com/specs/source/vocabs/commerce
Manu Sporny:  it might belong in the pay vocab for credit cards,
   bank accounts, etc.
Dave Longley:  Yeah, I think we're mostly in agreement 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.
Manu Sporny: http://payswarm.com/vocabs/commerce#payee
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: http://payswarm.com/vocabs/commerce#rate
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.
Manu Sporny:  but i'm ok with keeping it in the commerce vocab
   since there are good arguments either way.
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.
Manu Sporny:  a transfer is the movement of money ... multiple
   transfers are contained in a transaction.
Manu Sporny:  both of those are commerce terms.
Manu Sporny:  we need to discuss the pay vocab in a little more
   depth as to what it actually does.
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

Topic: Credit Card Vocabulary

Manu Sporny: http://payswarm.com/vocabs/creditcard
David I. Lehn: http://payswarm.com/specs/source/vocabs/creditcard
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.
Manu Sporny:  (this is how it related to payswarm)
Manu Sporny:  the result of a charge is that money is pulled out
   of a credit card and put into a storage account online.
Manu Sporny:  we need to add a bank/banking source.
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.
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.
Manu Sporny:  we probably just want "card" instead of credit
   card.
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
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?
Dave Longley:  probably just "pay" with a prefix of "pay"
Manu Sporny:  going down to the properties, we have brand...it's
   a text string like "visa", etc.
Manu Sporny:  that's fine, we have expiration dates, years,
   verification code, etc, all things associated with cards.
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...
David I. Lehn:  do we want to use some kind of xsd year/month
   type for those properties so we can use semweb tech?
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.
David I. Lehn: http://www.w3.org/TR/xmlschema-2/#gYear
David I. Lehn: http://www.w3.org/TR/xmlschema-2/#gMonth
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
Manu Sporny:  we'll just do that for now, try and make that work.
Manu Sporny:  name and address have been replaced by the vcard
   vocab.
Manu Sporny:  there are lots of payment services that we would
   want to be able to mark up too
David I. Lehn:  each one is a bit different
Manu Sporny:  there's dwolla, paypal, etc. no generalized
   solution for this, so we should wait until these thigns are
   supported
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
David I. Lehn:  how do we handle cash?
Manu Sporny:  that's outside of the system and your handling
   deposits which puts you into bank territory
Manu Sporny:  if we're talking about a pay vocab then cash is a
   mechanism
David I. Lehn:  we're going a little too far, we should leave it
   open-ended enough to handle it in the future
Manu Sporny:  is there anything else to discuss?
Dave Longley:  we're good.
Manu Sporny:  there's another question about the pay vocab...
Manu Sporny:  is there any overlap with opentransact?
Dave Longley:  there's some overlap with email addresses to/from
   and possibly paypal, etc. We should wait until we have a better
   OpenTransact representative here to discuss.

Topic: PaySwarm Vocabulary

Manu Sporny: http://payswarm.com/vocabs/payswarm
David I. Lehn: http://payswarm.com/specs/source/vocabs/payswarm
Manu Sporny:  for the classes we have asset, contract, data is
   something we don't use
Manu Sporny:  data is a type of asset, people will want to use it
   so we should keep it
Manu Sporny:  we have license, etc. we need these things.
Manu Sporny:  webpage is a bit weird ... maybe we want an assets
   vocabulary
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.
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?
David I. Lehn:  what's the difference in meaning?
David I. Lehn:  could it all be collapsed into a resource or
   something because it's the same?
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.
Manu Sporny:  we could have byte ranges or other things specified
   to talk about data
Manu Sporny:  you could specify a file, etc. we just don't have a
   byte range example
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
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.
Manu Sporny:  we could have separate classes for this that would
   better clarify this or the property meaning
Manu Sporny:  we might just break this up into sections to make
   the vocab a little clearer
Dave Longley:  it's sort of a way to add in layers like david
   nicol mentioned on the previous call
David I. Lehn:  we might have a better generalized way to
   approach all this so i think we need more experience
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.
Manu Sporny: http://www.productontology.org/
Manu Sporny:  this describes any type of product you can think
   of, we could possibly reuse this.
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
Manu Sporny:  maybe if we're doing crowd funding ... there is an
   example of asset that needs to be processed differently
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...
David I. Lehn:  there may be extensions, etc., but this shouldn't
   be free form
Manu Sporny:  we could get rid of webpage now if we're not using
   it to affect processing
Manu Sporny:  and we tell people to use another vocab to mark
   things up how they want to be more descriptive
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.
Manu Sporny:  the next thing that's up is the no additional
   payees rule.
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
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.
Manu Sporny:
   http://payswarm.com/specs/source/vocabs/payswarm#asset
Manu Sporny:  we definitely need that, assets are in contracts,
   receipts, they are what's for sale.
Manu Sporny:
   http://payswarm.com/specs/source/vocabs/payswarm#assetAcquirer
Manu Sporny:  next is assetAcquirer
David I. Lehn:  yes, we use it
Dave Longley:  yes, i believe so
Manu Sporny:  assetProvider ... do we need that?
Dave Longley:  yes
Manu Sporny:  do we need authority?
Manu Sporny:  can't we get that from the asset provider?
David I. Lehn:  that isn't necessarily true, i didn't think those
   were bound together
Dave Longley:  it might be used to specify the ID in the client
   config
David I. Lehn:  i think we should do that a different way
Manu Sporny:  there might be an argument to push a .well-known
   linked data services thing that can be served up in JSON-LD
David I. Lehn:  i think how it's being used now is confusing,
   pointing it at a config URL
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.
Manu Sporny:
   http://payswarm.com/specs/source/vocabs/payswarm#authority.
Dave Longley:  the spec might need to be updated to cover that
   use.
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.
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?
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
David I. Lehn:  we might be able to avoid this now for webpages,
   but we'll immediately have a need for it
David I. Lehn:  for any raw data stream that can't have embedded
   asset information in it
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.
Manu Sporny:  should we use content URL or just content.
David I. Lehn:  i think we had a reason to do it at some point
   ...
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.
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.
Manu Sporny:  let's drop it.
Dave Longley:  we should drop URL, but we might change it to
   assetContent or something more explicit
David I. Lehn:  why do we need "asset" there?"
Manu Sporny: http://dublincore.org/documents/dcmi-terms/
Dave Longley:  you can move properties around outside of an
   asset, there might be some confusion if it isn't general enough
Manu Sporny:  maybe we should use something from dublin core?
David I. Lehn:  do we need to support more structure/data
   formats, etc?
Manu Sporny:  we could allow base64-encoding content instead of
   it being a URL, etc.
David I. Lehn:  it seems like it might be a case that comes up
   with buying ebook formats, etc. various different formats.
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
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.
Manu Sporny:  let's just use content for now.
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
Manu Sporny:  ok, we're at the top of the hour, we'll finish up
   the payswarm vocab
Manu Sporny:  and get the documents updated.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Website for Developers Launched
http://digitalbazaar.com/2012/02/22/new-payswarm-alpha/

Received on Tuesday, 3 April 2012 19:26:24 UTC