Hi Kevin,
Thanks for your feedback. As for the two issues: (01)
a) Using URIs for CEFACT units of measurement instead of plain strings.
========================================================= (02)
The motivation for recommending (03)
gr:hasUnitOfMeasurement "GRM"^^xsd:string . (04)
instead of (05)
gr:hasUnitOfMeasurement rec20:GRM (06)
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 (07)
http://www.unece.org/cefact/recommendations/rec20/rec20_rev4E_2006.xls (08)
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. (09)
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. (010)
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. (011)
(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.) (012)
The current approach decouples the evolution of GoodRelations and the
evolution of the UN/CEFACT code. (013)
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. (014)
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. (015)
So, IMO, the current modeling does not create, any future compatibility
problem while ensuring GoodRelations can be adopted immediately (and it is). (016)
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). (017)
b) rdf:value instead of gr:hasValueInteger (and gr:hasValueFloat,
respectively)
=========
rdf:value can be useful for point values, but note that (018)
xyz gr:hasValueInteger "1"^^xsd:int (019)
is a shortcut for (020)
xyz gr:hasMinValueInteger "1"^^xsd:int
xyz gr:hasMaxValueInteger "1"^^xsd:int (021)
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. (022)
The details are given in (023)
http://www.heppnetz.de/projects/goodrelations/primer/#5.1_Handling_of_Ranges_and_Intervals (024)
and in the technical report at (025)
http://www.heppnetz.de/projects/goodrelations/GoodRelations-TR-final.pdf (026)
Also, http://www.w3.org/TR/rdf-primer/#example21 explicitly says that
rdf:value is just one way of representing values. (027)
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.) (028)
Hope that clarifies the motivation for the GoodRelations design choices. (029)
Best wishes (030)
Martin (031)
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
>>
>> (032)
--
--------------------------------------------------------------
martin hepp
e-business & web science research group
universitaet der bundeswehr muenchen (033)
e-mail: mhepp@xxxxxxxxxxxx
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 (034)
Check out the GoodRelations vocabulary for E-Commerce on the Web of Data!
======================================================================== (035)
Webcast:
http://www.heppnetz.de/projects/goodrelations/webcast/ (036)
Talk at the Semantic Technology Conference 2009:
"Semantic Web-based E-Commerce: The GoodRelations Ontology"
http://tinyurl.com/semtech-hepp (037)
Tool for registering your business:
http://www.ebusiness-unibw.org/tools/goodrelations-annotator/ (038)
Overview article on Semantic Universe:
http://tinyurl.com/goodrelations-universe (039)
Project page and resources for developers:
http://purl.org/goodrelations/ (040)
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 (041)
http://www.ebusiness-unibw.org/wiki/GoodRelations_Tutorial_ESWC2009 (042)
martin_hepp.vcf
Description: Vcard
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2009/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2009
Community Portal: http://ontolog.cim3.net/ (01)
|