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

[msporny]

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 #25 Payment Method Identifier Registry.

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

[halindrome]

Is there some clever way we can leverage the Schema.org work here too?
Create community-defined vocabularies for the various common terms that we
are using all over the place so they have semantic meaning everywhere
instead of just within our own protocols and messaging?

On Sun, Dec 6, 2015 at 4:09 PM, Manu Sporny notifications@github.com
wrote:

The Payment Method Identifiers
http://wicg.github.io/paymentrequest/specs/method-identifiers.html 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 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 #25 #25
Payment Method Identifier Registry.

Spec refs:

http://wicg.github.io/paymentrequest/specs/method-identifiers.html#introduction

http://web-payments.github.io/web-payments-messaging/#payment-instrument-registration

—
Reply to this email directly or view it on GitHub
#29.

Shane McCarron
halindrome@gmail.com

[msporny]

Is there some clever way we can leverage the Schema.org work here too?

I spoke with @danbri (Dan Brickley, schema.org, Google) about it at W3C TPAC and he seemed to welcome bringing some of our payment vocab stuff into schema.org. Also note that Good Relations has already been integrated, so a large amount of the Commerce stuff we intend to work on eventually is already defined in schema.org.

In general, +1 to use schema.org terms first, or attempt to put them into schema.org instead of maintaining our own vocabs.

[ianbjacobs]

The quoted sentences make no mention of distributed extensibility. I do not see how to infer Linked Data from the parts of the spec you quoted.

Having said that, if the identifiers can be either URIs or WG-approved short strings, you get distributed extensibilitly through URIs.

[msporny]

The quoted sentences make no mention of distributed extensibility.

Sorry, forgot to include another quote from the Payment Request Architecture document that does mention distributed extensibility. Changed the title of the issue to reflect more clearly what I was trying to get at.

if the identifiers can be either URIs or WG-approved short strings, you get distributed extensibilitly through URIs.

It's true that you get distributed extensibility for the identifiers. It is not true that you get distributed extensibility for the messages.

[adrianhopebailie]

It's true that you get distributed extensibility for the identifiers. It is not true that you get distributed extensibility for the messages.

Do we need distributed extensibility for the messages?

[msporny]

Migrated to w3c/payment-request#45.