(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>
