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] [ontology-summit] [Fwd: Re: Progressing a Units Ontology -virtual session]

Martin Hepp (UniBW) martin.hepp at ebusiness-unibw.org
Wed Jul 8 12:08:07 CEST 2009


Hi Kevin,
Thanks for your feedback. As for the two issues:

a) Using URIs for CEFACT units of measurement instead of plain strings.
=========================================================

The motivation for recommending

    gr:hasUnitOfMeasurement "GRM"^^xsd:string .

instead of

      gr:hasUnitOfMeasurement rec20:GRM

was (and still is) that at the time of releasing GoodRelations, there 
was no authoritative URI schema for UN/CEFACT available. The only 
official resource is

http://www.unece.org/cefact/recommendations/rec20/rec20_rev4E_2006.xls

I think such an authoritative URI schema for UN/CEFACT codes would be 
valuable, but it is not there, and GoodRelations should not have been 
delayed by that. A key design principle for GoodRelations is to built on 
currently available standards and tools - here and now, today.

Also, using URIs for those codes would be most useful if those URIs were 
dereferencable, which will likely not be the case if we just make up a 
URI pattern. Creating that may also require legal clearance from the UN. 
I tried the same for the UNSPSC and have been unable to release a proper 
OWL transcript for 1.5 years now.

A second requirement for me is that any OWL ontology or simple URI 
schema for UNCEFACT is immediately in sync with any update of the 
UN/CEFACT schema. I cannot rely on an OWL/RDFS or lightweight LOD 
transcript of the codes that will only be maintained as long as the 
sponsoring research project is up and running or the PhD student is 
interested in the work.

(There are dozens of non-maintained, outdated "single snapshot" 
transcripts of various coding schemes in OWL or RDFS on the Web. They 
are not only useless but dangerous traps for businesses adopting the 
technology. If you want, I can send you pointers, but I donÄt want to 
blame anyone publicly.)

The current approach decouples the evolution of GoodRelations and the 
evolution of the UN/CEFACT code.

We also considered Wikipedia/dbPedia URIs (same for currencies and 
locations), but again, there is the problem of a) keeping that in sync 
with updates of the standard, and, more difficult, making sure that a 
user can easily generate the URIs from the proper UN/CEFACT code string, 
because that is what they have in their RDBMS.

By the way, I think it should be possible to map the current 
GoodRelations pattern to any such URI schemes using restrictions on 
string values or regex patterns within SPARQL CONSTRUCT queries.

So, IMO, the current modeling does not create, any future compatibility 
problem while ensuring GoodRelations can be adopted immediately (and it is).

Bottom line: If there is an authoritative, and ideally dereferencable, 
URI schema for UN/CEFACT unit codes, I will be happy to consider 
changing the range from xsd:string to URI. Until then, I think that the 
current approach serves businesses best (that code as a string is used 
in thousands of corporate databases as of today).

b) rdf:value instead of gr:hasValueInteger (and gr:hasValueFloat, 
respectively)
=========
rdf:value can be useful for point values, but note that

xyz gr:hasValueInteger  "1"^^xsd:int

is a shortcut for

xyz gr:hasMinValueInteger  "1"^^xsd:int
xyz gr:hasMaxValueInteger  "1"^^xsd:int

because GoodRelations models *all* quantitative values as intervals 
instead of point values, because this allows simple queries using range 
constraints, both on the supply side ("we repair TV sets between 0 and 
50 inches screen size") and the demand side / query ("find all TV sets 
with at least 20 inches screen size"). This has shown to be very, very 
helpful for many real-world scenarios.

The details are given in

http://www.heppnetz.de/projects/goodrelations/primer/#5.1_Handling_of_Ranges_and_Intervals

and in the technical report at

http://www.heppnetz.de/projects/goodrelations/GoodRelations-TR-final.pdf

Also, http://www.w3.org/TR/rdf-primer/#example21 explicitly says that 
rdf:value is just one way of representing values.

I also do not see your owl:Restriction and owl:allValuesFrom patterns 
working well with very lightweight reasoning support. GoodRelations, but 
intension, requires just transitivity of rdfs:subClassOf and 
rdfs:subPropertyOf. (It could also be that rdf:value a 
owl:DatatypeProperty turns the model into OWL Full, not sure about that.)

Hope that clarifies the motivation for the GoodRelations design choices.


Best wishes

Martin


Kevin D. Keck wrote:
> Yuck.  Forgive me, but why are the units of measure in GoodRelations 
> encoded as unqualified strings?  This violates rule #1 of Tim 
> Berners-Lee's Linked Data note[1]:
>
> 1. Use URIs as names for things
>
> If URIs were used, then it would be straight-forward to make 
> statements in another ontology about the different units.  Because 
> URIs are not used, it is instead difficult to do so in any way that 
> off-the-shelf tools will recognize.  There is no reason why the CEFACT 
> data types cannot be transcribed into OWL/RDF in a way that makes 
> explicit the coding scheme(s) used for supplementary components, using 
> URI prefixes (e.g. rec20:GRM and rec20:HUR, instead of 
> "GRM"^^xsd:string and "HUR"^^xsd:string).
>
> In the interest of converging on common RDF patterns for values with 
> supplementary components, I would also suggest utilizing the rdf:value 
> property built-in to RDF, in precisely the way illustrated in the RDF 
> Primer[2].  OWL is fully capable of expressing specific type 
> constraints on the rdf:value provided for each particular 
> GoodRelations Value class, using allValuesFrom axioms, e.g.:
>
>
> rdf:value a owl:DatatypeProperty ;
>     a owl:FunctionalProperty .
> gr:QuantitativeValue
>     rdfs:subClassOf [a owl:Restriction ;
>         owl:onProperty rdf:value ;
>         owl:cardinality "1"^^xsd:int] .
> gr:QuantitativeValueFloat
>     owl:intersectionOf (
>         gr:QuantitativeValue
>         [a owl:Restriction ;
>             owl:onProperty rdf:value ;
>             owl:allValuesFrom xsd:float ]
>     ) .
> gr:QuantitativeValueInteger
>     owl:intersectionOf (
>         gr:QuantitativeValue
>         [a owl:Restriction ;
>             owl:onProperty rdf:value ;
>             owl:allValuesFrom xsd:int ]
>     ) .
>
>
> The target RDF patterns would then be:
>
>
> default:SonyCellPhoneModel_s1234
>       a gr:ProductOrServiceModel ;
>       default:hasTalkTime default:QuantitativeValueInteger_9 ;
>       default:hasWeight default:QuantitativeValueFloat_10 .
>
> default:QuantitativeValueFloat_10
>       a gr:QuantitativeValueFloat ;
>       rdfs:comment "The value node representing a weight of 100 
> grams"^^xsd:string ;
>       rdf:value "100.0"^^xsd:float ;
>       gr:hasUnitOfMeasurement rec20:GRM .
>
> default:QuantitativeValueInteger_9
>       a gr:QuantitativeValueInteger ;
>       rdfs:comment "The node representing a time duration of 120 
> hours."^^xsd:string ;
>       rdf:value "120"^^xsd:int ;
>       gr:hasUnitOfMeasurement rec20:HUR.
>
>
> Is it just me who thinks that looks a whole lot better, as a target?
>
> [1] http://www.w3.org/DesignIssues/LinkedData.html
> [2] http://www.w3.org/TR/rdf-primer/#example21
>
>
>
> On Jul 7, 2009, at 12:01 PM, Martin Hepp (UniBW) wrote:
>
>> Hi all:
>> Just a pragmatic request: Whatever the outcome of the activity will 
>> be: Please aim at being able, eventually, to do unit conversion at 
>> least for the subset of UN/CEFACT listed at
>>
>> http://www.heppnetz.de/projects/goodrelations/primer/#6_ANNEX:_POPULAR_UN.2FCEFACT_COMMON_CODES 
>>
>>
>> AND make sure you can do that on the basis of RDF patterns of the form
>>
>>
>> default:SonyCellPhoneModel_s1234
>>       a gr:ProductOrServiceModel ;
>>       default:hasTalkTime default:QuantitativeValueInteger_9 ;
>>       default:hasWeight default:QuantitativeValueFloat_10 .
>>
>> default:QuantitativeValueFloat_10
>>       a gr:QuantitativeValueFloat ;
>>       rdfs:comment "The value node representing a weight of 100 
>> grams"^^xsd:string ;
>>       gr:hasValueFloat "100.0"^^xsd:float ;
>>       gr:hasUnitOfMeasurement "GRM"^^xsd:string .
>>
>> default:QuantitativeValueInteger_9
>>       a gr:QuantitativeValueInteger ;
>>       rdfs:comment "The node representing a time duration of 120 
>> hours."^^xsd:string ;
>>       gr:hasValueInteger "120"^^xsd:int ;
>>       gr:hasUnitOfMeasurement "HUR"^^xsd:string .
>>
>> IMO, the significance of any work in the field of units of 
>> measurements will depend on the gain in automated harmonization or 
>> translation of quantitative values expressed in different but 
>> compatible units.
>>
>> Of course, this requires a sound conceptual approach. But without a 
>> service that can exploit the conceptual structures representing the 
>> "conversion knowledge", the impact of any such endeavor will be very 
>> limited, IMHO.
>>
>> Martin
>>
>>

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

e-mail:  mhepp at computer.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 the GoodRelations vocabulary for E-Commerce on the Web of Data!
========================================================================

Webcast:
http://www.heppnetz.de/projects/goodrelations/webcast/

Talk at the Semantic Technology Conference 2009: 
"Semantic Web-based E-Commerce: The GoodRelations Ontology"
http://tinyurl.com/semtech-hepp

Tool for registering your business:
http://www.ebusiness-unibw.org/tools/goodrelations-annotator/

Overview article on Semantic Universe:
http://tinyurl.com/goodrelations-universe

Project page and resources for developers:
http://purl.org/goodrelations/

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

http://www.ebusiness-unibw.org/wiki/GoodRelations_Tutorial_ESWC2009




-------------- 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/20090708/ca6bbd72/attachment.vcf>


More information about the goodrelations mailing list