Matthias Wiesmann

Would it make sense to have a common ancestor to both Legislation and Decision? For instance [legislationIdentifier](https://schema.org/legislationIdentifier) could be shared. Generally, there are many redundant fields, `decisionDatePublished` feel redundant given...

That makes sense, a new property on IndividualProduct would make sense.

The _period after opening_ would also be a candidate, it is very often present on cosmetic symbols, in a coded way: https://wiesmann.codiferes.net/wordpress/archives/29169

Yes, maybe what we need is to mention these at the right (product) level

Just some random ideas: Can you just model this with CreativeWork and MediaObject? ```json { "@context": "https://schema.org", "@type": "MediaObject", "name": "Quarx Model" "description": "3DModel for Quarx", "isBasedOn": { "@type": "Thing",...

I would distinguish between two uses of ISO 6523. - As a root for the OID tree. - As a meta system for organization identifiers. As mentioned above, the DUNS...

@[thadguidry](https://github.com/thadguidry) You assume two things: - That a country only has one Tax-ID number format. - That a company's tax / vat identifiers are from the country their address is...

My main point is that ISO 6523 solves two problems: type identification and formatting. If I understand [PropertyValueSpecification](https://schema.org/PropertyValueSpecification), we would need to have 1+ per country and it would not...

Sadly, things are _complicated_. - Australia has VAT, Australian VAT numbers are not prefixed with `AU`. - European VAT numbers are prefixed with the country code if they are intercommunity...

> I much prefer property/value pairs in JSON-LD, and how I usually handle it. I have always found property/value pairs (semantics, which allows easier information exchange) to be easier to...