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 / EAN/UPC

Martin Hepp (UniBW) martin.hepp at ebusiness-unibw.org
Mon May 25 12:40:21 CEST 2009


(including the mailing list in my reply)

Dear Alex:

I see the point - the problem with turning gr:hasEAN_UCC-13 into an 
owl:InverseFunctionalProperty is, as far as I can see, that

1. there is no canonical way of deriving a URI or URN from a given 
EAN/UCC-13 code. At least, I don't know of any. And unless there is an 
authoritative URI for each EAN/UCC-code, you can still not avoid custom 
inferencing.

2. There may be unwanted side-effects (even if rare), because the same 
gr:ProductModel may have multiple EAN/UCC codes, and, more importantly, 
EAN/UCC codes can be attached both to gr:ProductModels and gr:Offerings 
(which is based on how EAN/UPC identifiers are used in the value chain - 
they can be attached to commodity makes and models and to sales units, 
e.g. bunles or variants).

This is why, for the moment, I favor using custom inferencing to link 
all records that

1. Are of the same type (e.g. are both gr:ProductOrServices or both 
gr:Offerings
AND
2. Have the same EAN/UCC.

Note that two instances x and y whith x being an instance of 
gr:ProductOrService and y being and instance of gr:Offering MUST NOT be 
merged into one by owl:sameAs or other axioms, because 
gr:ProductOrService and gr:Offering are disjoint.

Best

Martin

Alex Cozzi wrote:
> Thanks Martin.
> A question: the gr:hasEAN_UCC-13 is very useful for unifying objects 
> across databases, but currently is a datatype property. I was 
> wondering whether defining a reverse functional property 
> (owl:InverseFunctionalProperty) that points to a URI version of the 
> EAN_UCC-13 would be possible/desiderable.  I am not sure what is the 
> standard uri representation of EAN_UCC-13, but having such property 
> would reduce the amount of custom inference needed to unify product 
> descriptions.  Does it make sense?
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: martin_hepp.vcf
Type: text/x-vcard
Size: 308 bytes
Desc: not available
URL: <http://ebusiness-unibw.org/pipermail/goodrelations/attachments/20090525/7dd5afe4/attachment.vcf>


More information about the goodrelations mailing list