Should Payment Method Identifiers and Messages be expressed using a Linked Data Vocabulary?

[msporny]

Migrating from w3c/webpayments#29:

The Payment Method Identifiers spec states:

The PaymentRequest API requires that merchants supply a list identifiers for supported payment methods. This document defines those identifier strings and how they are created.

The Payment Request Architecture spec states:

we expect some message definitions to be shared amongst different payment apps.

The two sets of spec proposals agree that:

• There should be a list of identifiers for payment methods.
• There should be shared attributes across payment apps and methods.
• There should be short names for payment methods.
• We should support distributed extensibility.

This sounds an awful lot like a Linked Data vocabulary. Is it?

This is related to #11.

Spec refs:
http://wicg.github.io/paymentrequest/specs/method-identifiers.html#introduction
http://web-payments.github.io/web-payments-messaging/#payment-instrument-registration

[adrianba]

This is a duplicate of issues #11 and #10. Today the answer to the question "Is it Linked Data vocabulary" is no. If you prefer the answer to be yes, we need a proposal for the Method Identifiers specification.

[msporny]

This is a duplicate of issues #11 and #10.

Issue #11 is just about Payment Method Identifiers.

Issue #10 is just about short codes for payment method identifiers.

This issue is about PMIs and the content of payment messages. It takes a more holistic view around how we're going to achieve a solution for #10 and #100. Specifically, this issue asks whether or not some/all of the 'key's and 'value's of the objects map to URLs.

I do agree that using a Linked Data Vocabulary expressed as JSON-LD would resolve #10, #11, and #45 in one fell swoop, but I don't think the rest of the WG is there yet, so would rather keep these issues separate for now (and assert that while there is overlap, the issues don't duplicate one another).

[ianbjacobs]

@msporny,

"Specifically, this issue asks whether or not some/all of the 'key's and 'value's of the objects map to URLs."

Could you say more about what requirement(s) you have in mind?

Ian

[msporny]

Could you say more about what requirement(s) you have in mind?

The requirements are at the top of this issue. I'll re-state them again and link the 'keys' and 'values' text above to the requirements stated at the beginning of the issue:

• There should be a list of identifiers for payment methods ('values').
• There should be shared attributes ('keys') across payment apps and methods.
• There should be short names for payment methods ('values').
• We should support distributed extensibility.

We could also extend/refine those with more basic requirements for the payment messages like:

• identifiers (values) should at least use a universal identifier mechanism (e.g. URLs)
• there should be a mechanism to shorten universal identifiers (e.g. short names)
• there should be a way to disambiguate keys shared among different JSON documents (e.g. by mapping them to URLs in some way)
• support linking to data outside of the message (e.g. by using URLs to point to things like offers, images, etc.)
• support internationalization for data values (with the ability to support the expression of the data value in multiple languages in the same message - 'payment request in countries that have more than one "native" language')
• a way to associate datatypes with values (e.g. dates, times, currencies)

I agree that some of these are "nice-to-have"s, but some of them are "must have"s, and it'll be up to the WG to decide where that line is.

[adrianba]

I thought that the WG had concluded that using Linked Data was only an option and not required by the specifications. Therefore I think the answer to the question raised by this issue "Should Payment Method Identifiers and Messages be expressed using a Linked Data Vocabulary?" is no and I recommend that we close this issue.

[ianbjacobs]

That aligns with my understanding.
Ian

[dlongley]

My understanding is that this issue is about determining if the features that we need essentially constitute a Linked Data vocabulary, in which case we should consider using one, instead of reinventing the wheel. I don't think we've pinned down the features we need yet, so this issue should remain open until we do. Then we can determine if those features could be provided by adopting an existing technology.

[adrianhopebailie]

We resolved that the API specification will have no dependency on JSON-LD but that data passed to the API should be passed on to payment apps (and visa versa) opaquely such that if it is JSON-LD (and therefor contains members such as @context or @vocabulary etc) these will not be stripped out.

On the back of that there was discussion around producing a document that provided guidance on extensibility detailing how JSON-LD may be used to acheive this.

I don't believe we are all on the same page yet with regard to the need to produce a JSON-encoded payment request out of the back of the API (to be passed on to payment apps). We need to agree that this is a requirement first before we talk about how we will extend that JSON object. I can see how anyone that doesn't consider that a requirement would be wondering what this question even means with regard to "Messages". (With regard to payment method identifiers there is #10 and #11 which, if resolved will either recommend the use of a Linked-Data dictionary or not)

Right now the only extension point defined for the browser API is the ability to pass custom payment method data into the request. It's possible that a future payment method specification will use JSON-LD as a means of describing the custom data that it uses but to date the only proposals/specs put forward (Basic Card and SEPA) do not.

I'm not going to close this issue but I don't see the WG making any progress on resolving it at such an abstract level without some concrete proposals that demonstrate exactly what the Linked Data vocabulary options would look like.

[ianbjacobs]

I propose we close this issue. We have picked absolute URLs for PMIs. We have decided not to require JSON-LD in the paymentRequest specification. There were no objections to publishing a "how to use JSON-LD with this API" spec. If the question comes up concretely in the context of the HTTP API spec, we can address it there.

Ian