The product page offers two sizes for each product. For example Coca-Cola 1liter and Coca-Cola 0.5liter. Above is the productname "Coca-Cola" and beneath of that comes the "Coca-Cola" description. Is it possible to insert both sizes into the schema.org markup or do i have to choose one productsize and just ingnore the other size/price?
I assume that you refer to Thing > Product
Product is defined as:
anything that is made available for sale — for example, a pair of shoes, a concert ticket, or a car.
In e-commerce world anything that is made available for sale is called SKU (stock-keeping unit) and product is usually a container for SKUs (I said usually, as different platforms can have different terms or data structures).
So from your description I see that your system has a product which is "A bottle of Coca-Cola" with two SKUs:
1-litter bottle of Coca-Cola
0.5-litter bottle of Coca-Cola
I would use information of the SKUs for schema.org Product.
Some schema.org attributes comes from parent product (in your case A bottle of Coca-Cola) e.g. url (assuming you have two SKUs: 1-litter and 0.5-litter on the same page) or description (assuming you have generic description coming from product). But some other attributes like weight (or size / price) will be specific for each bottle. There is also sku attribute which usually refers to your SKU number.
As a side note, you can find similar challenge when building, say, Google Product Feed, and the similar approach will work perfectly fine.
I hope that will help.
Related
I have been asked by a customer to develop a "product configurator", and i need some inputs on how to handle the DB part of the project.
Each product can have a subset of different precreated attributes.
The minimum is 1 attribute, but there is no maximum.
Some attributes have dependencies/relationships with other attributes.
Eg. If the product is a chair, you need to choose the material (wood, plastic, metal), and you need to choose which type of legs the chair shoud have.
If the Product is a cabinet, you still need to choose a material, but instead of legs there will be different doors to choose from etc.
Each of these attributes might have subattributes. Eg. the door has a color, a size and a doorhandle.
Then the door handle has a material, a type and so on.
This ultimatly ends up in a multi-layered attribute-tree.
By itself this isnt too complicated to code, however the customer wants to be able to manage (Create, update and delete) all products, attributes and relationships between attributes, within the webapp.
So coding the relationship-part isn't a viable solution.
I have gone with a EAV model to facilitate the "potential unlimited" amount of attributes each product can have.
But i am struggling to figure out how to go about the "attribute relationships".
A simplified version of my DB design looks like this:
If each product could subscribe to groups of attributes that is legal. Then each attribute belongs to a group like "wood group".
Then the user could set the groups of attributes against a product that should need to be answered to configure a product.
With regards managing a tree, you could use a column type of hierarchyid . Or construct an outline string as key field.
An outline for example
1.
1.1.
1.1.1.
1.2.
2.
2.1.
I'm struggling to understand how i need to do this. So my problem: I'm supposed to allow someone to sell a product on a website. Before selling, he has to chose a certain category. Each category has different characteristics that could be marked, and those characteristics are entirely dependent on the chosen category. The values of those characteristics are predefined, and are already put in the database.
My question now is how do i go on about this? How do i link those characteristics to the chosen category, and how do i link the different amounts of predefined values to those specific characteristics?
example:
category: keyboard
characteristics: condition (dropdown), keyboard layout(dropdown), extra options(multiple choice)
condition has 3 options: new, as good as new, used
keyboard layout has 2 options: qwerty, azerty
extra options is multiple choice, has 3 options: gaming keyboard, wireless, 60%
second example:
category: laptop
characteristics: condition (dropdown), refresh rate(dropdown)
condition has 3 options: new, as good as new, used
refresh rate has 5 options: 50hz, 60hz, 120hz, 144hz, 240hz
Now i would have to make this work in my database, but i can't even figure it out on a relational database diagram.
Any form of help would certainly be appreciated!
I would distribute fields like this:
CATEGORIES (keyboard, laptop)
id
name
ATTRIBUTES (refresh_rate, layout)
id
name
FEATURES (50hz, 60hz, qwerty, etc)
id
attribute_id
name
CATEGORIES_ATTRIBUTES
id
category_id
attribute_id
PRODUCTS
id
name
category_id
condition (could be an enum, I put it here as every product has a condition)
PRODUCT_FEATURES
product_id
attribute_id (redundant but it can save you a join when making queries)
feature_id
Cheers!
I run table tennis products website.
I need to add product specification and way for users be able to compare between products on their specs.
Example the following product page : product example
Every blade like above will have its speed and control quality number.
So need to put this on above product page like :
Speed : 89
Quality: 70
And users can compare specs with other products side by side.
I understand I can just input the above spec on product description, but then it does not have compare system,
users will have to manualy open two screens, and thats difficult for mobile users.
Is there any in-build solution in shopify or any app that can do this ?
You can do it but it is not a straight forward way.
Create all additional fields using metafields property of the products. More information - https://help.shopify.com/themes/liquid/objects/metafield
Create a comparison "page" where you can provide 2/3/4 drop lists for products to be used for comparison
Create a template for products that displays the comparison data in JSON notation. More information - https://help.shopify.com/themes/customization/store/create-alternate-templates
As soon as a product is selected in "2", do an AJAX call to the product template in "3". You'll get the required data. Now you can arrange it in any format as you need.
I'm a bit confused with Sqlite, Core Data, NSUserDefaultsand PropertyList. I know what is what, but not a very clear idea of about where to appropriately use them.
I know that there are lots of tutorials, but I'm good at learning through situation based understanding. So kindly do help me to understand this in the situation that I'm facing right now and to make use of the available options wisely.
I'm working on an ECommerce iOS (native) application, where I'm highly dependent on API's for data display. Now I'm in need of recording user's review for a product and send it over through an API.
ie. I have three components, rating title, rating value(for that title) and another rating title ID. I'm defining with an example, I need to store multiple rows with details,
Components Data to be stored
**Title** - Quality | Value | Price
| |
**Rating** - 2 | 3 | 1
| |
**TitleID** - 10 | 11 | 12
Like this, there will be so many entries, i.e, the number of components differs for various users, for some users, there might be more than three components, which must be saved & send through an API. So how should I save these data? which is the RIGHT way to save these data temporarily?
If I understand you correctly, as vaibhav implied your question seems pretty general and probably relates more to structuring your data to fit your requirements than to technical aspects of the iOS / CoreData environment. In that vein, I’ll offer a few thoughts I’d have in structuring a data structure for quality ratings per your description.
If your ratings will always be for the three categories you show, i.e. Quality, Value and Price, I wouldn’t over-complicate things; I’d just use three properties in a rating record to hold the values that a user assigns in his/her rating of a product (just showing selected attributes and relationships in all following lists):
Product
name
Rating
ratedProduct (many to one)
qualityRating Int
valueRating Int
priceRating Int
Done this way you’d need to associate the values with their types in code for the APIs, such as (where item is a retrieved rating record):
display(product: item.ratedProduct.name, quality: item.qualityRating, value: item.valueRating, price: item.priceRating).
On the other hand, you may be describing a more generic approach that would allow for ratings categories that vary more frequently, or perhaps vary among products. This could apply where, for example, ratings include how well things fit for clothing but not for other products like books. In that case, you’d need a more complicated structure where a product could have a variable number of ratings of different types, so you’d need another layer of entities that let you create an arbitrary number of rating records that applied to a product.
Here you'd create a separate rating record for each rating that a user assigned to a product.
The simplest form of that structure would be like the following:
Product
name String
UserEvaluation
ratedProduct (many to one)
productRating (one to many)
ProductRating
ratingType (many to one)
value Int
RatingType
ratingTitle String
ratingID String or Int
Then you’d have to have a bit more structure where you'd list the product and then access the ratings with a loop that cycled through the set of all of the ratings linked to the product record somewhat like this (where item is a retrieved UserEvaluation):
displayTitle(product: item.ratedProduct.name)
for rating in item.productRating {
displayRating(ratingTitle: item.productRating.ratingType.title, ratingValue: item.productRating.value)
}
You'd probably want to combine these into a method that takes the name and an array of ratings.
To keep track of things, you’d also probably want to create another entity that defined product classes and specified what specialized ratings applied to each class (like fit for clothing and mileage for cars). By default, you also may want to allow for a few generic rating types that apply to all products (like the quality and price ratings you show). For this approach, the full structure would look like this:
Product Category
title
ratingType (many to many)
Product
productType (many to one)
UserEvaluation
ratedProduct (many to one)
productRating (one to many)
ProductRating
ratingType (many to one)
value Int
RatingType
ratingTitle String
ratingID String or Int
With this structure, once a product is assigned a productType, the application would know what ratings to ask for in the UI.
You could try building more complicated rating records with all of the types that apply to a product category, but that would get very messy if the applicable categories vary over time. You could also create a "custom" rating type that let a user specify a title and input a rating, in which case you'd need a text field in the rating record that only applies if the ratingType is "custom".
I hope this helps…
We create point of sale software for the mac, and are looking to revamp our tax engine. It's pretty simple now, with taxes consisting of a name, code and rate that can be applied to every product individually. While this is good enough for some people, we've had lots of requests to handle more advanced situations. Some examples are US City/County sales tax, Canadian compound (stacked) taxes, French ecotax and NYC luxury tax.
We've identified most of the characteristics that these taxes have and are leaning towards a sort of rule-engine based implementation. We don't have to support every case out there, but we want to be able to extend it if needed (to avoid another rewrite).
We're looking for advise from people who built something like this before, or examples of projects that try to solve the same in an elegant way.
My suggestion would be to use database tables for what they are good for (storing values) and rules for what they are good for (business logic). I would certainly not put things like tax rates or lists of jurisdictions in rules - those should be in tables. What I would use a rules engine for is defining the logic that determines which rate to apply to which transactions. So, for instance, if I buy a set of products online from a company based in State X that ships from State Y to three different locations, what tax rates apply to which parts of the transaction?
This combination of rules and database tables is very common - the rules make sure you look up the right things while the tables aid in reporting etc. For instance, the California DMV did this with vehicle registration fees - all the various fees are stored in a database while the rules that determine which fee applies to which car are managed in a rulebase.
If you try and put everything in rules you will not be able to report well and if you try and put everything in database tables you will end up with dozens of tables to manage all the exceptions and corner cases.
JT
I would recommend a set of database tables and joins.
Example:
Jurisdiction: list of states, counties, countries, cities, etc.
Product: obvious
Store: list of locations you sell from
StoreJurisdiction(StoreID, JurisdictionID): the list of Jurisdictions the store is
responsible to collect taxes for
ProductTaxCode(ProductID int, TaxCodeID int): the type of product for the purposes of taxes: basic, luxury, etc.
JurisdictionTaxCodeRate(JurisdictionID, TaxCodeID, InterestRate, RateType): for each applicable combination of Jurisdiction and Tax Code, provide the tax rate to be applied, and the type of rate (compound, simple, etc.).
To find the list of taxes to apply, all you need is an INNER JOIN of the store, its jurisdictions, the jurisdictiontaxcoderates for those Jurisdictions, and the product's tax codes.
You could define ProductTaxCode as a View so all products receive a default TaxCode unless a special one is provided. By abstracting TaxCode, you can have the same metadata about a product ("Food" for instance) apply to different regions in different ways. If a particular jurisdiction has its own definition of "food", you just add a jurisdiction-specific code and apply it to products as needed.
This may require some tweaking for Internet purchases, wholesale purchases, and other situations where the sale is somehow exempt from taxes or the customer is responsible for remitting them. It would also need tweaking for situations where the customer's location, rather than the store, decides the tax rate.
Other tweaks: here in Texas, for instance, we have a "tax-free" weekend where state and local taxes are not collected on some classes of products where the individual item's sale price is less than $100. The idea is to provide cheaper school supplies, clothing, etc. for children heading off to school for a new year. This sort of tweak could be implemented by having a date range table for each JurisdictionTaxCodeRate going off in the future as far as they can be planned.
Here is an example of a "home rule" city in the Denver, CO metropolitan area:
http://www.c3gov.com/pages/about/division_salestax.html
You, as a retailer, may also need to send the tax payments to different locations. For cities that are not "home rule" cities (which is a special term that probably only applies to Colorado, but then probably every state has some equally special term like it), you'll send all the tax payments to the state who will then deal them out to the relevant parties. Colorado has a feature where there are "special tax districts" that are permitted to collect sales taxes for certain benefits (on the example link, RTD is the public transportation district, and "Invesco Field" is the stadium where the Denver Broncos play).
To expand upon Mr Tallent's answer on this thread, you'll need to also include in the Jurisdiction table some way of representing that the taxes may go to different places.