- From: Kévin Dunglas <dunglas@gmail.com>
- Date: Tue, 28 Jan 2014 23:14:08 +0100
- To: Martin Hepp <martin.hepp@ebusiness-unibw.org>
- Cc: public-vocabs@w3.org
Hi Martin, and thanks for reviewing my proposals. My answers are inline. 2014/1/28 Martin Hepp <martin.hepp@ebusiness-unibw.org>: > I will look into your various proposals as far as they touch the e-commerce model in schema.org. > In the past, we considered extending the tax modeling in GoodRelations, but we postponed that, mainly for two reasons: > > 1. GoodRelations focusses on the discovery phase of business transactions. In that phase, a detailed modeling of taxes and fees is less important. Also, the VAT property was not really used a lot. I fully understand your argument. However, the current vocable is very close to be a full (even if simple) and standard e-commerce data model. I'm trying to use it it as a foundation for an open-source e-commerce software. There are some gaps and taxes are a major one. As said in my first message, almost all e-commerce platforms have tax support: * Magento: http://www.magentocommerce.com/knowledge-base/entry/ce18-and-ee113-setup-taxes-step3 * Prestashop: http://doc.prestashop.com/display/PS15/Understanding+Local+Settings#UnderstandingLocalSettings-Taxes * Sylius: http://docs.sylius.org/en/latest/bundles/SyliusTaxationBundle/tax_rates.html There are a lot of uses for extracting taxes of e-commerce websites (e.g. create an offer aggregator displaying prices without VAT for B2B in Europa). > 2. Very often, the applicable tax is not a fixed property for a single offer, but depends on the country (or in the US even the state) of delivery, so you end up with with a ternary relation between a price specification, a country, and tax details. In some cases, even the legal status of the buyer will have influence (for instance, in B2B scenarios in Europe, there is no VAT, while in B2C scenarios, the VAT of the country of origin applies). For the localization problem, some solutions exists: * The easiest: create one offer by country/region. schema.org/PriceSpecification already has a priceCurrency property so it is not very flexible. * Add the same eligibleRegion property that schema.org/Offer has. An offer can have many schema.org/PriceSpecification so one PriceSpecification by region can be created (with the according tax amount). For the B2B/B2C problem, my proposal address it. Depending of the legal status of the buyer, a software agent can display the price tax excluded or add it with the provided VAT. > 3. The applicable taxes follow certain (often complicated rules); materializing those at the level of each single price information seems problematic. The proposal is to add taxes amounts, not percentages or rules. Only the result of the computation should be included in the PriceSpecification. > > I will propose a generic property-value pattern to schema.org asap; maybe we can use that to provide a pattern for tax information. Good news. Properties are really missing to this vocable! Is there a draft available? > > Martin > > On Jan 26, 2014, at 11:00 AM, Kévin Dunglas wrote: > >> Hi, >> >> A great addition to http://schema.org/PriceSpecification would be >> taxes. There already is a valueAddedTaxIncluded property but: >> * This property is not sufficient to compute the amount of the VAT. >> The VAT rate varies by country. It can even be different in the same >> country depending of the product or service's type. >> * It tells nothing about other taxes that apply such as ecotax. For >> instance, the french law requires displaying the ecotax amount to >> customers. >> >> Moreover, most i18n/l10n enabled e-commerce platforms (including >> Magento and Prestashop) provide a Tax data model. >> >> >> I propose to add the following property to >> http://schema.org/PriceSpecification: >> >> Property | Expected Type | Description >> ------------------------- | ---------------------------------- | >> ---------------------------------------------------------------------------------------------------- >> applyingTax | ApplyingTax | One or more tax >> applying to this price (included in the price property) >> >> And the following types: >> >> http://schema.org/ApplyingTax >> >> Property | Expected Type | Description >> ------------ | ----------------------- | >> ---------------------------------------------------------------------------------------------------- >> tax | Tax | The type of tax >> amount | Number or Text | The amount of the tax >> >> >> http://schema.org/Tax >> >> Instances of Tax: >> * http://schema.org/ValueAddedTax >> * http://schema.org/Ecotax >> >> Let me know if it sounds interesting. In such case I'll make a formal >> RDFa proposal. >> -- >> Kévin Dunglas >> >> http://dunglas.fr >> >> > > -------------------------------------------------------- > martin hepp > e-business & web science research group > universitaet der bundeswehr muenchen > > e-mail: hepp@ebusiness-unibw.org > phone: +49-(0)89-6004-4217 > fax: +49-(0)89-6004-4620 > www: http://www.unibw.de/ebusiness/ (group) > http://www.heppnetz.de/ (personal) > skype: mfhepp > twitter: mfhepp > > Check out GoodRelations for E-Commerce on the Web of Linked Data! > ================================================================= > * Project Main Page: http://purl.org/goodrelations/ > > > -- Kévin Dunglas http://dunglas.fr
Received on Tuesday, 28 January 2014 22:14:57 UTC