Web Payments Community Group Telecon

Minutes for 2012-05-01

  1. PaySwarm Vocabulary
  2. Prefixed-terms vs. keywords for PaySwarm 1.0
  3. Webcredit spec concerns
  4. Currency IRIs
  5. Enforce-ability of amounts in currencies
  6. Range of vocabulary terms
  7. Fragment Identifiers
Manu Sporny
Dave Longley
Dave Longley, Manu Sporny, David I. Lehn
Audio Log
Dave Longley is scribing.
Manu Sporny: We're going to discuss the payswarm vocabulary and the webcredit spec. Anything else for today?

Topic: PaySwarm Vocabulary

Manu Sporny: We were on the "owner" term.
Dave Longley: We use ps:owner for a lot of different things, we need an ownership term. This is in the same state that it was in before. [scribe assist by Manu Sporny]
Dave Longley: We already talked about ownership; it's still in limbo.
Dave Longley: We were looking for another term for it from another vocabulary.
Manu Sporny: Do we want an external term or not? [scribe assist by Manu Sporny]
Manu Sporny: do we want to keep owner here?
Dave Longley: We might want to layer it.
Dave Longley: We should keep it for now, it might move to another vocab or be "layered" (like discussed before) but it is needed.
Manu Sporny: moving on, validFrom specifies when some information begins being valid
Manu Sporny: validUntil indicates when the validity period ends
Manu Sporny: We certainly need this, we use it for keys, listings, etc.
David I. Lehn: Is the reliable terminology the right usage here?
Dave Longley: It refers to a validity period.
David I. Lehn: ok
Manu Sporny: maybe we should put these things in RDF Schema vocabulary (core web resource thing) (owner/validFrom/validUntil)
David I. Lehn: We don't have control over that
Manu Sporny: We can ask them to add it.
Manu Sporny: I don't think there's any question it is the right thing to do, it's just a question as to whether or not we can get it done in a reasonable time frame.
Manu Sporny: I'll talk to some people (Ivan Herman, etc.) about this.
Manu Sporny: yeah, there were several things I have to talk to people about here.
Manu Sporny: I will talk with W3C to see if we can get these terms into a vocab.
Manu Sporny: that's that for the payswarm vocabulary.
Manu Sporny: anything else that needs to be discussed?
Manu Sporny: We didn't really discuss the payment vocab.
Dave Longley: and we may just make it a "layer" within the payswarm vocab.

Topic: Prefixed-terms vs. keywords for PaySwarm 1.0

Manu Sporny: a couple of people (eg: Pelle) have raised the point that it would be nice if we could just use terms
Manu Sporny: rather than prefixes
Manu Sporny: I think the vocabs are simple enough so that we could do that using the payswarm context
Manu Sporny: the keys are unique enough so that we don't have conflicts right now
Manu Sporny: the question is whether or not we want to support that or stay with prefixes
Manu Sporny: so do we just want to use just plain terms?
Dave Longley: I think prefixed-terms are going to turn many people away from PaySwarm... the folks that don't care about Linked Data. [scribe assist by Manu Sporny]
Dave Longley: It might be a good idea to just use terms, I think it'll just be more attractive for folks. [scribe assist by Manu Sporny]
David I. Lehn: Are we sure there are no conflicts/ [scribe assist by Manu Sporny]
Manu Sporny: If there are, we can change the vocabulary term to something else. [scribe assist by Manu Sporny]
Manu Sporny: of course people and extend this if they want to.
Manu Sporny: We allow people to use prefixed-values if they want to, right? [scribe assist by Manu Sporny]
Dave Longley: yes, that's what JSON-LD is for. [scribe assist by Manu Sporny]
Manu Sporny: ok, I think we're all in agreement
David I. Lehn: lots of code we'll have to make.
Manu Sporny: In the long run this will be better.

Topic: Webcredit spec concerns

David I. Lehn: the JSON-LD spec has matured enough that we can use it as intended to deal with this.
Manu Sporny: yes.
David I. Lehn: Can you summarize what was going on in the thread(s)?
Manu Sporny: Michiel de Jong is the project lead for the unhosted project
Manu Sporny: they are trying to do decentralized payments, etc. decentralized everything.
Manu Sporny: let you have your own data service that provides your pictures, payments, everything that facebook/twitter uses, etc.
Manu Sporny: so what is the type of URI that you use when you want to make a payment?
Manu Sporny: Can you use a mailto: URI?
Manu Sporny: Can someone take a currency message that says "EUR" and agree to it?
Manu Sporny: How are different currencies resolved/specified by URI, text, etc?
Manu Sporny: It seems like Michiel's argument is that people will challenge the type of currency specified if how a currency is specified isn't in the spec
Manu Sporny: I think that if there's something that says { "amount": "5", "currency": "EUR" } in the document, I don't think courts would have a problem with that
Manu Sporny: I think it would be clear what you intended to pay someone.
David I. Lehn: I thought it was odd that anyone would think there was an issue at all.
Manu Sporny: right; I think we're in agreement
Manu Sporny: His issues one by one:
Manu Sporny: He said he's struggling with the vagueness of the syntax
Manu Sporny: He says ... what if someone uses a mailto: In the currency field
Manu Sporny: because any URI will do
Manu Sporny: I'm not sure that's actually what the spec says
Manu Sporny: the payswarm spec; so there may be no issue there.
Manu Sporny: He said he wants the URI to point to a document explaining what the currency is
Manu Sporny: We wanted to actually go further, we wanted it to be an endpoint where you could hit the URI and be able to get a certain amount of the currency.
David I. Lehn: I don't know how far we want to go with this but it doesn't really matter with the URIs are ...
David I. Lehn: you can dereference it, but you can just use other semweb stuff to describe that URI.
David I. Lehn: If you use a mailto: It's weird, and I don't know why you'd do that
Manu Sporny: He's saying you don't have interoperability if you do that
Manu Sporny: If two apps use different kinds of URIs they are non-interoperable
David I. Lehn: It isn't that one is at fault, it's just that they aren't agreeing on a common currency
Manu Sporny: sounds like its out of scope
Dave Longley: This is not any different from having an app that don't support a currency. [scribe assist by Manu Sporny]
Dave Longley: just viewing the currency field as a string ...
Dave Longley: If you want to exchange value, both apps have to agree on the currency. [scribe assist by Manu Sporny]
Dave Longley: If you don't support a certain currency you can't talk to the apps that do.
Dave Longley: It doesn't matter what the actual string is.
Manu Sporny: yes, both apps have to understand a currency value, that's it.
Manu Sporny: It's like if someone came up to a US counter and tried to pay in EURO it wouldn't work if they didnt' accept that.
Manu Sporny: It's not different than trying to pay with "mailto:".
David I. Lehn: yes, we should just try to better explain this.
Manu Sporny: We're in agreement.

Topic: Currency IRIs

David I. Lehn: there may be some other standards /currency IDs that are in IRI form that we could use
David I. Lehn: that might somewhat help with this
Manu Sporny: there might be an IRI form with the ISO for currencies
David I. Lehn: I dont' know there's a common standard that has IRIs in it.
Manu Sporny: We say currency code in the spec because we know that we can do that
Manu Sporny: If someone makes an IRI that people accept in the future we'll just add support for that.
David I. Lehn: It would be nice to not special case currency
Manu Sporny: yes, but I don't think the world is there yet
Manu Sporny: and we don't want to have to solve that problem in PaySwarm 1.0 - we can always say we support "USD" today and "http://some-official-currency.org/currencies/USD" in the future.
David I. Lehn: Could we just claim our own IRIs?
Manu Sporny: We'd have to go through a process that would be problematic.
Manu Sporny: at the end it would be the W3C saying "here are the URLs for the currencies in the world", and they won't be willing to do that w/o buy in from major banks and standards-setting organizations.
Manu Sporny: getting that support might be a big political issue
David I. Lehn: I dont' know, maybe it wouldn't be.
David I. Lehn: this would certainly simplify our system and let us put descriptions, etc into these URLs
Dave Longley: Could we just use urn:currency, etc?
David I. Lehn: Well, it would make it an IRI and simplify how we handle things
Manu Sporny: let me see if there's an IRI for this
Manu Sporny: Six Interbank Clearing is the company that is in charge of this
(for providing codes and numbers for currencies)
Manu Sporny: I think it would be a pain to support the numbers
Manu Sporny: urn:iso4217:USD
Manu Sporny: should we do that just to be consistent?
Dave Longley: Let's try to find some standard that specifies IRIs for currencies, and if there is one, use that. If not, we can revisit. [scribe assist by Manu Sporny]

Topic: Enforce-ability of amounts in currencies

Manu Sporny: His next concern we sort of talked about already, if you go and buy a car and give a web credit of 2000 with a currency of EURO on it, (webcredits is an IOU system), lets say that after 2 months someone asks you for the IOU and you say that all the things you sign are in grains of sand ... so why do you want EUROs?
Manu Sporny: I think it's pretty clear what a court would do in this case
Manu Sporny: I don't think that any court would find that because the spec wasn't specific enough that the buyer was never intending to buy in EUROs but always in grains of sand
Dave Longley: We can just add a sentence that says: If you say amount and currency, then you mean the amount in that currency.
Dave Longley: to the spec; that will be easy.
Manu Sporny: I don't think we want to support self-issued currencies yet, which is something in the webcredits spec
Dave Longley: I agree
(discussion about webcredits spec ... doesn't really apply to payswarm)
Dave Longley: We just have to have core support for that sort of thing in payswarm, we don't need support specifically
Dave Longley: We made payswarm to allow extensions like this
David I. Lehn: I agree
Dave Longley: (refers to lots of extra contract-related things that can be implemented on top of base PaySwarm spec in WebCredits spec)

Topic: Range of vocabulary terms

Manu Sporny: the payswarm spec says what goes into source and destination ... which may be different from what the vocab says (more limited)
Dave Longley: sounds fine to respond by saying there's no issue if the vocab terms are broad but the spec narrows it down for specific messages.

Topic: Fragment Identifiers

Manu Sporny: Michiel says everyone uses a hash URL to mean a document fragment (identify something within a document), but this breaks machine readibility
Manu Sporny: Michiel said: "everybody uses the # to mean document fragment, and the definition of a URL-with-fragment as both the document and its topic breaksmachine-readability. "
Manu Sporny: this is HTTP range 14 territory, let's not spend much time on it
Dave Longley: What this comes down to is this:
Dave Longley: a # can be interpreted by a client however it wants to, we have a specific kind of client that participates in payswarm (a linked data aware PaySwarm client) and we mandate how to interpret those hashes
Manu Sporny: next ...
Manu Sporny: some other concerns about the webcredits spec ... that, conversely, we should have covered in payswarm
Manu Sporny: His concern is about who owes who in a document, the spec needs to be clear and really the graphical interfaces being used to transact must actually be clear.
Manu Sporny: I think we've discussed most of Michiel's concerns

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