Warning: This tool or project is no longer maintained and kept available only for archival purposes. Since GoodRelations and schema.org have evolved significantly in the past years, the current status available on this page is unlikely to function as expected. We take no responsibility for any damage caused by the use of this outdated work, to the extent legally possible.

Due to a lack of resources, we are unable to provide support for this project outside of consulting projects or sponsored research. Please contact us if you can contribute resources to update and enhance these resources.

GoodRelations - The Web Vocabulary for E-Commerce

This is the archive of the goodrelations dicussion list

GoodRelations is a standardized vocabulary for product, price, and company data that can (1) be embedded into existing static and dynamic Web pages and that (2) can be processed by other computers. This increases the visibility of your products and services in the latest generation of search engines, recommender systems, and other novel applications.

[goodrelations] GoodRelations + RDFa have huge impact on Google Rank and CTR

Martin Hepp (UniBW) martin.hepp at ebusiness-unibw.org
Mon Dec 14 13:04:10 CET 2009

hi giovanni,

>> hurry for that.. and they work right away in the inspector
>> http://sindice.com/developers/inspector/?url=http%3A%2F%2Fproducts.semweb.bestbuy.com%2Fy%2Fproducts%2F7590289%2F#sigma
>> Yes, but please also show key values like price, payment, and delivery
>> options, even if those require parsing a single intermediate node.
> Martin can typeand quantity and unitprice and offering node exist on
> their own really ?
No, not really, so you can usually create them as blank nodes with no 
harm. But you need them as individual nodes because that is the only 
valid modeling pattern for higher arity relations in RDFS/OWL.
But there are cases where you want to reuse such nodes, e.g. when you 
have multiple offers that just differ by e.g. the eligible country or 
other properties of the gr:Offering.

>  I can and will do something speacial for goodrelations for sigma but
> i cannot but wonder if the model needs those pieces, Sigma also
> commits to provide a simplified RDF to people who want it.
The models needs those pieces. There is no other proper way if 
separating units from values etc.

You can hide the complexity of higher arity relationship types in any 
user interface. But you cannot eliminate them in your conceptual model. 
Premature simplification is evil (D. Knuth, if I remember correctly).

>  I could understand providing not just a key value pair description
> but an extra noda saying for example "iphone" (node1)   ---> "find it
> on sale at bestbuy for $199" (node2, a node with all those other
> properties attached) but yet more and more nodes (e.g. 2-3 like here)
> seems too much.  Could i come up with a simplified node that is the
> offerincludingunitpricetypeandquantity node?  to give to my sigma
> users? :-) how about adding that to goodrelations?
No, no, no!

Why don't you just collate that on the presentation level? Why messing 
up the representation level?

Separation of concerns is key!
> wrt inspector and visualization please note that a complete "human
> readably" rdf representation is also available e.g. here
> http://sindice.com/developers/inspector/?url=http://products.semweb.bestbuy.com/y/products/7590289/&doReasoning=true#fullcontent
> which is complete, albeit less intuitive than the sig.ma representation.
That looks much better to me.
> should we put this one first instead of sig.ma? should we allow the
> user to pick which node sigma looks at (sig.ma is entity based, needs
> to pick 1 node).
Hmm. Why not use tabs? But again - the need to conflate a few 
intermediate nodes does not force you to show the full raw model as a 
first view. Just fix the handling of the few extra nodes - quantitative 
values and price specs mainly - and use that to improve the simpler view.
> notice that soon we will be announcing the inspector as a
> omnicomprehensive tool for validating web data, syntactically
> (including the w3c validation), semantically, and more (best practice
> validator including the "pedantic" web validation, linked ontology
> check (already in place), so we want this to be as good as developer
> friendly/useful as possible.
> So suggestions are very welcome!!
See above - thanks for your important initiative!

>> Also, you should use the ean ucc 13 property to suggest related entities,
>> even if this is a literal value instead of a URI.
> how to use it for suggestions?
Simply search for entities that have the same property-value pair AND 
that are of the same type (both gr:ProductAndServiceModel) and then 
suggest that they are sameAs. But be careful, multiple entities of 
different types can have the same property, too.


> cheers!
> Giovanni

martin hepp
e-business & web science research group
universitaet der bundeswehr muenchen

e-mail:  hepp at 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 page:

Resources for developers:

Overview - http://www.heppnetz.de/projects/goodrelations/webcast/
How-to   - http://vimeo.com/7583816

Recipe for Yahoo SearchMonkey:

Talk at the Semantic Technology Conference 2009: 
"Semantic Web-based E-Commerce: The GoodRelations Ontology"

Overview article on Semantic Universe:

Tutorial materials:
ISWC 2009 Tutorial: The Web of Data for E-Commerce in Brief: A Hands-on Introduction to the GoodRelations Ontology, RDFa, and Yahoo! SearchMonkey 

More information about the goodrelations mailing list