Clean-up PaymentMethod

[MatthiasWiesmann]

The list of enum values for PaymentMethod points to the goodrelations web-site which seems to have been updated last in 2008, the last messages on its mailing lists were in 2016.

The list of payments is incomplete, it is missing big players like ApplePay while including dead projects like PaySwarm.

I don't think that maintaining a complete list of online payment lists would scale. Instead I would suggest adding a PaymentMethod class between PaymentCard and FinancialProduct, which would include additional fields like:

• Currency
• Geographical scope

For insance

{
  "@context": "https://schema.org",
  "@type": "PaymentMethod",
  "name": "Twint",
  "currency": "CHF",
  "provider": {
    "@type": "Organization",
    "name": "TWINT AG",
    "url": "https://www.twint.ch/"
   }
}

I would also update PaymentCard with a property to reflect security features like 3D secure.

[MatthiasWiesmann]

The following methods of payment also need to be added:

• Carrier payments
• Pay in convenience stores (very common is Asia)

[rrlevering]

The problem with this change is that it's now written (in the PaymentMethod docs) that the existing goodrelation enums are valid but that's not true if you make PaymentMethod structured. Enums are essentially modeled as primitive values in schema.org (strings or urls) in practice and if you make the type a non-enum then it cannot support raw strings. So all the existing schema.org online is now invalid. Maybe consider adding Text to the range of acceptedPaymethodMethod with this list added there as supported legacy values and mention that you can represent the same thing (the goodrelation URLs) with a suggested structured value?

[MatthiasWiesmann]

Pull request #2996 should fix this.

[jvandriel]

If you don't mind me asking, why is this change needed?

I was always under the assumption schema.org's datamodel specifies that every value can be a Text or URL value, even if it hasn't been specified in vocabulary definitions.

[MatthiasWiesmann]

I was always under the assumption schema.org's data model specifies that every value can be a Text or URL value, even if it hasn't been specified in vocabulary definitions.

Technically, this is not the case, although my parsers apply Postel's principle and accept way more than the schema specifies.

[rrlevering]

I believe that was an original idea with schema.org but it's not practical for consuming or validating the data. It means every predicate would need to also specify a string format or something to be generally consumable into a more complex object. So we've gradually been moving it to be more explicit. Most of Google's systems do not allow that flexibility. We either drop the raw strings or more frequently coerce them into objects with names. Try it in the schema markup validator on a predicate that doesn't support Text.

…

On Wed, Sep 25, 2024, 10:18 AM Matthias Wiesmann ***@***.***> wrote: I was always under the assumption schema.org's data model specifies that every value can be a Text or URL value, even if it hasn't been specified in vocabulary definitions. Technically, this is not the case, although my parsers apply Postel's principle and accept way more than the schema specifies. — Reply to this email directly, view it on GitHub <#3537 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADNUGYQOSSONWF2HU5S53LZYLA4TAVCNFSM6AAAAABID453HSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZUGIZDMOBUGM> . You are receiving this because you commented.Message ID: ***@***.***>

[philbarker]

I believe that was an original idea with schema.org but it's not practical for consuming or validating the data.

Most of Google's systems do not allow that flexibility.

In that case you should probably update https://schema.org/docs/datamodel.html which still says:

Although it might be helpful for search applications if structured data markup always followed schema.org very strictly, in practice this is unrealistic.

and

We also expect that often, where we expect a property value of type Person, Place, Organization or some other subClassOf Thing, we will get a text string, even if our schemas don't formally document that expectation. In the spirit of "some data is better than none", search engines will often accept this markup and do the best we can.

[jvandriel]

"I believe that was an original idea with schema.org"

I've been around long enough to assume my assumption was based on that.

The Datamodel page still somewhat refers to it in its conformance section (emphasis mine):

"We expect schema.org properties to be used with new types, both from schema.org and from external extensions. We also expect that often, where we expect a property value of type Person, Place, Organization or some other subClassOf Thing, we will get a text string, even if our schemas don't formally document that expectation. In the spirit of "some data is better than none", search engines will often accept this markup and do the best we can. Similarly, some types such as Role and URL can be used with all properties, and we encourage this kind of experimentation amongst data consumers."

Thanks for your answers @MatthiasWiesmann and @rrlevering.

[rrlevering]

I'm not sure I'm suggesting a major change, but I think just a slightly milder wording. I think the "search engines will often accept this markup and do the best we can" doesn't necessarily indicate that it's "correct". While in practice we might get a string because syntaxes like Microdata can make it harder to get structured objects, the consumers are going to have to figure out how to turn any strings into valid objects if a predicate only has structured values in its range. But I do think there should be an assumption that the string will conceptually map onto something in its valid range.

…

On Thu, Sep 26, 2024 at 9:26 AM Jarno van Driel ***@***.***> wrote: "I believe that was an original idea with schema.org" I've been around long enough to assume my assumption was based on that. The Documentation page still somewhat refers to it in its conformance section <https://schema.org/docs/datamodel.html#conformance> (emphasis mine): "We expect schema.org properties to be used with new types, both from schema.org and from external extensions. We also expect that often, *where we expect a property value of type Person, Place, Organization or some other subClassOf Thing, we will get a text string, even if our schemas don't formally document that expectation. In the spirit of "some data is better than none", search engines will often accept this markup and do the best we can*. Similarly, some types such as Role <https://schema.org/Role> and *URL <https://schema.org/URL> can be used with all properties*, and we encourage this kind of experimentation amongst data consumers." Thanks for your answers @MatthiasWiesmann <https://github.com/MatthiasWiesmann> and @rrlevering <https://github.com/rrlevering>. — Reply to this email directly, view it on GitHub <#3537 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADNUG33KNKUXNNIMXBZZWTZYQDRBAVCNFSM6AAAAABID453HSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZWHE3TGOBUGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[github-actions]

This issue is being nudged due to inactivity.