From fps at semanlink.net Sat Jan 26 13:56:24 2013 From: fps at semanlink.net (=?iso-8859-1?Q?Fran=E7ois-Paul_Servant?=) Date: Sat, 26 Jan 2013 13:56:24 +0100 Subject: [goodrelations] gr:ProductFeature Message-ID: <3441A39C-414C-4C05-814F-4AB4E21C08E2@semanlink.net> Hi, Some questions about "ProductFeature" http://wiki.goodrelations-vocabulary.org/Documentation/Product_features states that GoodRelations from release 2012-08-01 onwards supports a novel pattern based on gr:ProductFeature and gr:Feature I may be wrong, but the only online available specification of GR is "V 1.0, Release 2011-10-01", and it doesn't mention gr:feature and gr:ProductFeature. Are these features (!) actually included in GR? Or will they ever be? I'm interested because gr:ProductFeature seems to be very close to co:Specification, cf http://purl.org/configurationontology and a previous message on this list: http://ebusiness-unibw.org/pipermail/goodrelations/2012-November/000497.html To be noted: the page in gr wiki mentions http://schema.org/ProductFeature but that doesn't seem to exist. How does gr:feature and ProductFeature relate to vso:feature and vso:FeatureValue? fps From fps at semanlink.net Sat Jan 26 13:59:57 2013 From: fps at semanlink.net (=?iso-8859-1?Q?Fran=E7ois-Paul_Servant?=) Date: Sat, 26 Jan 2013 13:59:57 +0100 Subject: [goodrelations] vso:feature, dpPedia and productontology Message-ID: <13CA243D-B563-4E71-B391-71B8A4475F8D@semanlink.net> In http://www.productontology.org/#faq I read: "DBpedia URIs cannot be used for modeling the type of real-world objects, in particular in the context of the GoodRelations ontology, because - they lack a suitable semantics for being used as classes, and - they are not valid OWL DL." In http://www.heppnetz.de/ontologies/vso/ns#feature the comment about vso:feature says: "Use DBPedia resources to indicate the features, if possible." I don't see what they should be a difference between a product and a feature of a product wrt their modeling If it is bad to say that foo:mySolderingIron rdf:type dbPedia:Soldering_iron it must also be bad to say that foo:myRegulatedAirConditioner rdf:type dbPedia:Air_conditioner Best, fps From martin.hepp at ebusiness-unibw.org Mon Jan 28 10:07:20 2013 From: martin.hepp at ebusiness-unibw.org (Martin Hepp) Date: Mon, 28 Jan 2013 04:07:20 -0500 Subject: [goodrelations] vso:feature, dpPedia and productontology In-Reply-To: <13CA243D-B563-4E71-B391-71B8A4475F8D@semanlink.net> References: <13CA243D-B563-4E71-B391-71B8A4475F8D@semanlink.net> Message-ID: <834B243B-81FC-4C5A-B55B-E89A91B4AEEA@ebusiness-unibw.org> Hi Francois-Paul: On Jan 26, 2013, at 7:59 AM, Fran?ois-Paul Servant wrote: > In http://www.productontology.org/#faq > I read: > "DBpedia URIs cannot be used for modeling the type of real-world objects, in particular in the context of the GoodRelations ontology, because > - they lack a suitable semantics for being used as classes, and > - they are not valid OWL DL." > > In http://www.heppnetz.de/ontologies/vso/ns#feature > the comment about vso:feature says: > "Use DBPedia resources to indicate the features, if possible." > > I don't see what they should be a difference between a product and a feature of a product wrt their modeling > > If it is bad to say that foo:mySolderingIron rdf:type dbPedia:Soldering_iron > it must also be bad to say that > foo:myRegulatedAirConditioner rdf:type dbPedia:Air_conditioner The answer is simply, yet it may not obvious, so thanks for the question: You can (and should) use suitable DBPedia URIs for *instances* (individuals), but not for *classes* (types). All examples in the Vehicle Sales Ontology (http://purl.org/vso/ns) and other GoodRelations extensions say that you should rather use DBPedia URIs for instances of predefined value *types*. Example: VSO defines http://purl.org/vso/ns#BodyStyleValue as the range for http://purl.org/vso/ns#bodyStyle You can use http://dbpedia.org/resource/Convertible http://dbpedia.org/resource/Hatchback http://dbpedia.org/resource/Station_wagon http://dbpedia.org/resource/Sport_utility_vehicle http://dbpedia.org/resource/Roadster as a value for that property, in statements like foo:myCar vso:bodyStyle . An OWL/RDF reasoner will infer then that rdf:type vso:BodyStyleValue which is perfectly fine. Hope that helps! Best Martin > > > Best, > > fps > _______________________________________________ > goodrelations mailing list > goodrelations at ebusiness-unibw.org > http://ebusiness-unibw.org/cgi-bin/mailman/listinfo/goodrelations -------------------------------------------------------- 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 Main Page: http://purl.org/goodrelations/ From martin.hepp at ebusiness-unibw.org Mon Jan 28 10:47:04 2013 From: martin.hepp at ebusiness-unibw.org (Martin Hepp) Date: Mon, 28 Jan 2013 04:47:04 -0500 Subject: [goodrelations] gr:ProductFeature In-Reply-To: <3441A39C-414C-4C05-814F-4AB4E21C08E2@semanlink.net> References: <3441A39C-414C-4C05-814F-4AB4E21C08E2@semanlink.net> Message-ID: <33A55F3C-32D5-4DFD-B2F5-4D32B2FDB01D@ebusiness-unibw.org> Hi, On Jan 26, 2013, at 7:56 AM, Fran?ois-Paul Servant wrote: > Hi, > > Some questions about "ProductFeature" > > http://wiki.goodrelations-vocabulary.org/Documentation/Product_features states that > GoodRelations from release 2012-08-01 onwards supports a novel pattern based on > gr:ProductFeature and > gr:Feature > > I may be wrong, but the only online available specification of GR is "V 1.0, Release 2011-10-01", and it doesn't mention gr:feature and gr:ProductFeature. > > Are these features (!) actually included in GR? Or will they ever be? > They will be included in the next GoodRelations service update, available shortly (but unfortunately delayed more than I wanted it to be). > I'm interested because gr:ProductFeature seems to be very close to co:Specification, cf > http://purl.org/configurationontology > and a previous message on this list: > http://ebusiness-unibw.org/pipermail/goodrelations/2012-November/000497.html > > To be noted: the page in gr wiki mentions > http://schema.org/ProductFeature > but that doesn't seem to exist. > > How does gr:feature and ProductFeature relate to vso:feature and vso:FeatureValue? They are largely unrelated. gr:ProductFeature will be a convenient way of exposing product feature data if you have not more granularity than a propery name, a value, and maybe text for the unit. vso:feature is for using DBPedia URIs for indicating car features so that http://purl.org/vso/ns does not have to maintain a list of every feature available on the market. Martin > > fps > _______________________________________________ > goodrelations mailing list > goodrelations at ebusiness-unibw.org > http://ebusiness-unibw.org/cgi-bin/mailman/listinfo/goodrelations -------------------------------------------------------- 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 Main Page: http://purl.org/goodrelations/ From fps at semanlink.net Mon Jan 28 11:19:07 2013 From: fps at semanlink.net (=?windows-1252?Q?Fran=E7ois-Paul_Servant?=) Date: Mon, 28 Jan 2013 11:19:07 +0100 Subject: [goodrelations] vso:feature, dpPedia and productontology In-Reply-To: <834B243B-81FC-4C5A-B55B-E89A91B4AEEA@ebusiness-unibw.org> References: <13CA243D-B563-4E71-B391-71B8A4475F8D@semanlink.net> <834B243B-81FC-4C5A-B55B-E89A91B4AEEA@ebusiness-unibw.org> Message-ID: <01DA8C48-C2B6-4819-8CC9-0349CEEE38F1@semanlink.net> Hi Martin, thank you for your answers. I understand the difference between instance and class. My remark is more about usability and extensibility of the statements that we can make if we follow the recommendation to use dbPedia URIs as values for vso:feature-like properties vs if we use instances of the product ontology classes For instance, in the case of body styles, we could imagine to have 2 kinds of station wagons: full-size wagons and two-doors wagons (there are no corresponding URIs in dbPedia, but that's not the point here - let's imagine there are). One could want to state something like foo:myCar vso:bodyStyle . still hoping consumers of the data be able to infer that this is a special kind of station wagon. For that, we would need to have defined some kind of hierarchy between the values of body style. It could be defined using SKOS (OK with individuals, but dbPedia entities are not supposed to be skos concepts), or a hierarchy of classes. I think therefore that it would be better to use statements such as: foo:myCar vso:bodyStyle [ a productontology:Two_doors_wagon. ]. because if it is said somewhere that productontology:Two_doors_wagon rdfs:subClassOf productontology:Station_wagon we can infer using very simple reasoning that myCar's body style is also Station wagon. This argument against using dbPedia URI is probably not that strong for properties such as body styles, which have a limited, stable list of possible values. But for features, I think it is: a constructor describing the features of its range will not want to say, for instance: foo:myCar vso:feature dbPedia:SunRoof. It will want to say that: foo:myCar vso:feature [ a productOntology:SunRoof ; rdfs:label "Very large super cool sun roof different from all others"; ?(description of that wonderful sun roof: pictures, link to marketing blabla, etc) ] If you use a dbPedia URI as object in a statement involving vso:feature, you cannot give additional information about the feature in question. And, as a vendor, you want to. So I think that it can be counterproductive to advertise such a practice. fps Le 28 janv. 2013 ? 10:07, Martin Hepp a ?crit : > Hi Francois-Paul: > > On Jan 26, 2013, at 7:59 AM, Fran?ois-Paul Servant wrote: > >> In http://www.productontology.org/#faq >> I read: >> "DBpedia URIs cannot be used for modeling the type of real-world objects, in particular in the context of the GoodRelations ontology, because >> - they lack a suitable semantics for being used as classes, and >> - they are not valid OWL DL." >> >> In http://www.heppnetz.de/ontologies/vso/ns#feature >> the comment about vso:feature says: >> "Use DBPedia resources to indicate the features, if possible." >> >> I don't see what they should be a difference between a product and a feature of a product wrt their modeling >> >> If it is bad to say that foo:mySolderingIron rdf:type dbPedia:Soldering_iron >> it must also be bad to say that >> foo:myRegulatedAirConditioner rdf:type dbPedia:Air_conditioner > > The answer is simply, yet it may not obvious, so thanks for the question: > > You can (and should) use suitable DBPedia URIs for *instances* (individuals), but not for *classes* (types). > > All examples in the Vehicle Sales Ontology (http://purl.org/vso/ns) and other GoodRelations extensions say that you should rather use DBPedia URIs for instances of predefined value *types*. > > Example: > > VSO defines > > http://purl.org/vso/ns#BodyStyleValue > > as the range for > > http://purl.org/vso/ns#bodyStyle > > You can use > > http://dbpedia.org/resource/Convertible > http://dbpedia.org/resource/Hatchback > http://dbpedia.org/resource/Station_wagon > http://dbpedia.org/resource/Sport_utility_vehicle > http://dbpedia.org/resource/Roadster > > as a value for that property, in statements like > > foo:myCar vso:bodyStyle . > > An OWL/RDF reasoner will infer then that > > rdf:type vso:BodyStyleValue > > which is perfectly fine. > > Hope that helps! > > Best > Martin > > > >> >> >> Best, >> >> fps >> _______________________________________________ >> goodrelations mailing list >> goodrelations at ebusiness-unibw.org >> http://ebusiness-unibw.org/cgi-bin/mailman/listinfo/goodrelations > > > > -------------------------------------------------------- > 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 Main Page: http://purl.org/goodrelations/ > > > From martin.hepp at ebusiness-unibw.org Mon Jan 28 11:49:38 2013 From: martin.hepp at ebusiness-unibw.org (Martin Hepp) Date: Mon, 28 Jan 2013 05:49:38 -0500 Subject: [goodrelations] vso:feature, dpPedia and productontology In-Reply-To: <01DA8C48-C2B6-4819-8CC9-0349CEEE38F1@semanlink.net> References: <13CA243D-B563-4E71-B391-71B8A4475F8D@semanlink.net> <834B243B-81FC-4C5A-B55B-E89A91B4AEEA@ebusiness-unibw.org> <01DA8C48-C2B6-4819-8CC9-0349CEEE38F1@semanlink.net> Message-ID: My suggestion is that if you as a vendor have the authoritative power to define a certain feature, you should do so, e.g. as Volkswagen is doing in the VVO: http://purl.org/vvo/ns#GearboxDSG If you want to provide more information, you could alway define a value instance of a value type in your own namespace. The DBPedia recommendation is for those cases when a single data publishers is looking for a globally recognized identifier for a feature but does not have the power to introduce one, e.g. Peter Miller selling his car. Note that you should rather not use www.productontology.org classes for types of *features*, since they are designed to represent types of *products or services*. In some cases, a feature can be a product at the same time, but in many cases that does not hold. Also, I think that the new gr:ProductFeature pattern in the next GoodRelations release will provide a simpler mechanism for such scenarios anyway. Martin On Jan 28, 2013, at 5:19 AM, Fran?ois-Paul Servant wrote: > Hi Martin, > > thank you for your answers. > > I understand the difference between instance and class. My remark is more about usability and extensibility of the statements that we can make if we follow the recommendation to use dbPedia URIs as values for vso:feature-like properties vs if we use instances of the product ontology classes > > For instance, in the case of body styles, we could imagine to have 2 kinds of station wagons: full-size wagons and two-doors wagons (there are no corresponding URIs in dbPedia, but that's not the point here - let's imagine there are). One could want to state something like > > foo:myCar vso:bodyStyle . > > still hoping consumers of the data be able to infer that this is a special kind of station wagon. For that, we would need to have defined some kind of hierarchy between the values of body style. It could be defined using SKOS (OK with individuals, but dbPedia entities are not supposed to be skos concepts), or a hierarchy of classes. > > I think therefore that it would be better to use statements such as: > foo:myCar vso:bodyStyle [ > a productontology:Two_doors_wagon. > ]. > because if it is said somewhere that > productontology:Two_doors_wagon rdfs:subClassOf productontology:Station_wagon > we can infer using very simple reasoning that myCar's body style is also Station wagon. > > This argument against using dbPedia URI is probably not that strong for properties such as body styles, which have a limited, stable list of possible values. But for features, I think it is: a constructor describing the features of its range will not want to say, for instance: > foo:myCar vso:feature dbPedia:SunRoof. > It will want to say that: > foo:myCar vso:feature [ > a productOntology:SunRoof ; > rdfs:label "Very large super cool sun roof different from all others"; > ?(description of that wonderful sun roof: pictures, link to marketing blabla, etc) > ] > > If you use a dbPedia URI as object in a statement involving vso:feature, you cannot give additional information about the feature in question. And, as a vendor, you want to. So I think that it can be counterproductive to advertise such a practice. > > fps > > Le 28 janv. 2013 ? 10:07, Martin Hepp a ?crit : > >> Hi Francois-Paul: >> >> On Jan 26, 2013, at 7:59 AM, Fran?ois-Paul Servant wrote: >> >>> In http://www.productontology.org/#faq >>> I read: >>> "DBpedia URIs cannot be used for modeling the type of real-world objects, in particular in the context of the GoodRelations ontology, because >>> - they lack a suitable semantics for being used as classes, and >>> - they are not valid OWL DL." >>> >>> In http://www.heppnetz.de/ontologies/vso/ns#feature >>> the comment about vso:feature says: >>> "Use DBPedia resources to indicate the features, if possible." >>> >>> I don't see what they should be a difference between a product and a feature of a product wrt their modeling >>> >>> If it is bad to say that foo:mySolderingIron rdf:type dbPedia:Soldering_iron >>> it must also be bad to say that >>> foo:myRegulatedAirConditioner rdf:type dbPedia:Air_conditioner >> >> The answer is simply, yet it may not obvious, so thanks for the question: >> >> You can (and should) use suitable DBPedia URIs for *instances* (individuals), but not for *classes* (types). >> >> All examples in the Vehicle Sales Ontology (http://purl.org/vso/ns) and other GoodRelations extensions say that you should rather use DBPedia URIs for instances of predefined value *types*. >> >> Example: >> >> VSO defines >> >> http://purl.org/vso/ns#BodyStyleValue >> >> as the range for >> >> http://purl.org/vso/ns#bodyStyle >> >> You can use >> >> http://dbpedia.org/resource/Convertible >> http://dbpedia.org/resource/Hatchback >> http://dbpedia.org/resource/Station_wagon >> http://dbpedia.org/resource/Sport_utility_vehicle >> http://dbpedia.org/resource/Roadster >> >> as a value for that property, in statements like >> >> foo:myCar vso:bodyStyle . >> >> An OWL/RDF reasoner will infer then that >> >> rdf:type vso:BodyStyleValue >> >> which is perfectly fine. >> >> Hope that helps! >> >> Best >> Martin >> >> >> >>> >>> >>> Best, >>> >>> fps >>> _______________________________________________ >>> goodrelations mailing list >>> goodrelations at ebusiness-unibw.org >>> http://ebusiness-unibw.org/cgi-bin/mailman/listinfo/goodrelations >> >> >> >> -------------------------------------------------------- >> 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 Main Page: http://purl.org/goodrelations/ >> >> >> > > > _______________________________________________ > goodrelations mailing list > goodrelations at ebusiness-unibw.org > http://ebusiness-unibw.org/cgi-bin/mailman/listinfo/goodrelations -------------------------------------------------------- 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 Main Page: http://purl.org/goodrelations/ From fps at semanlink.net Mon Jan 28 14:42:03 2013 From: fps at semanlink.net (=?windows-1252?Q?Fran=E7ois-Paul_Servant?=) Date: Mon, 28 Jan 2013 14:42:03 +0100 Subject: [goodrelations] vso:feature, dpPedia and productontology In-Reply-To: References: <13CA243D-B563-4E71-B391-71B8A4475F8D@semanlink.net> <834B243B-81FC-4C5A-B55B-E89A91B4AEEA@ebusiness-unibw.org> <01DA8C48-C2B6-4819-8CC9-0349CEEE38F1@semanlink.net> Message-ID: <8AFB0E18-473B-4A67-93B7-8C9F4BF5E71F@semanlink.net> Martin, thanks again. All what you say makes sense to me. Of course a constructor will build its own URIs to define at least certain features, cf VW's GearboxDSG. I think that there are 2 conflicting goals in the description of features of products: on one side, big vendors want precise definitions of the features that they offer, what will bring them to use their own URIs. But on the other hand, consumers of that information (eg. web sites comparing offerings) need globally recognized identifiers : for instance, in comparing cars, they'll want to compare them regarding their air conditioner: first of all, do they have one or not? easier to say if a globally recognized identifier is used for it. To allow comparisons, features have to be typed, and, as far as possible, the types should have globally recognized identifiers (it is the case of GearboxDSG, which is a vso:TransmissionTypeValue. A range comparator can just display in the "vso:transmission" column the value found in the description of the car) I'm looking forward to learning more about gr:ProductFeature. Best, fps Le 28 janv. 2013 ? 11:49, Martin Hepp a ?crit : > My suggestion is that if you as a vendor have the authoritative power to define a certain feature, you should do so, e.g. as Volkswagen is doing in the VVO: > > http://purl.org/vvo/ns#GearboxDSG > > If you want to provide more information, you could alway define a value instance of a value type in your own namespace. > > The DBPedia recommendation is for those cases when a single data publishers is looking for a globally recognized identifier for a feature but does not have the power to introduce one, e.g. Peter Miller selling his car. > > Note that you should rather not use www.productontology.org classes for types of *features*, since they are designed to represent types of *products or services*. In some cases, a feature can be a product at the same time, but in many cases that does not hold. > > Also, I think that the new gr:ProductFeature pattern in the next GoodRelations release will provide a simpler mechanism for such scenarios anyway. > Martin > > On Jan 28, 2013, at 5:19 AM, Fran?ois-Paul Servant wrote: > >> Hi Martin, >> >> thank you for your answers. >> >> I understand the difference between instance and class. My remark is more about usability and extensibility of the statements that we can make if we follow the recommendation to use dbPedia URIs as values for vso:feature-like properties vs if we use instances of the product ontology classes >> >> For instance, in the case of body styles, we could imagine to have 2 kinds of station wagons: full-size wagons and two-doors wagons (there are no corresponding URIs in dbPedia, but that's not the point here - let's imagine there are). One could want to state something like >> >> foo:myCar vso:bodyStyle . >> >> still hoping consumers of the data be able to infer that this is a special kind of station wagon. For that, we would need to have defined some kind of hierarchy between the values of body style. It could be defined using SKOS (OK with individuals, but dbPedia entities are not supposed to be skos concepts), or a hierarchy of classes. >> >> I think therefore that it would be better to use statements such as: >> foo:myCar vso:bodyStyle [ >> a productontology:Two_doors_wagon. >> ]. >> because if it is said somewhere that >> productontology:Two_doors_wagon rdfs:subClassOf productontology:Station_wagon >> we can infer using very simple reasoning that myCar's body style is also Station wagon. >> >> This argument against using dbPedia URI is probably not that strong for properties such as body styles, which have a limited, stable list of possible values. But for features, I think it is: a constructor describing the features of its range will not want to say, for instance: >> foo:myCar vso:feature dbPedia:SunRoof. >> It will want to say that: >> foo:myCar vso:feature [ >> a productOntology:SunRoof ; >> rdfs:label "Very large super cool sun roof different from all others"; >> ?(description of that wonderful sun roof: pictures, link to marketing blabla, etc) >> ] >> >> If you use a dbPedia URI as object in a statement involving vso:feature, you cannot give additional information about the feature in question. And, as a vendor, you want to. So I think that it can be counterproductive to advertise such a practice. >> >> fps >> >> Le 28 janv. 2013 ? 10:07, Martin Hepp a ?crit : >> >>> Hi Francois-Paul: >>> >>> On Jan 26, 2013, at 7:59 AM, Fran?ois-Paul Servant wrote: >>> >>>> In http://www.productontology.org/#faq >>>> I read: >>>> "DBpedia URIs cannot be used for modeling the type of real-world objects, in particular in the context of the GoodRelations ontology, because >>>> - they lack a suitable semantics for being used as classes, and >>>> - they are not valid OWL DL." >>>> >>>> In http://www.heppnetz.de/ontologies/vso/ns#feature >>>> the comment about vso:feature says: >>>> "Use DBPedia resources to indicate the features, if possible." >>>> >>>> I don't see what they should be a difference between a product and a feature of a product wrt their modeling >>>> >>>> If it is bad to say that foo:mySolderingIron rdf:type dbPedia:Soldering_iron >>>> it must also be bad to say that >>>> foo:myRegulatedAirConditioner rdf:type dbPedia:Air_conditioner >>> >>> The answer is simply, yet it may not obvious, so thanks for the question: >>> >>> You can (and should) use suitable DBPedia URIs for *instances* (individuals), but not for *classes* (types). >>> >>> All examples in the Vehicle Sales Ontology (http://purl.org/vso/ns) and other GoodRelations extensions say that you should rather use DBPedia URIs for instances of predefined value *types*. >>> >>> Example: >>> >>> VSO defines >>> >>> http://purl.org/vso/ns#BodyStyleValue >>> >>> as the range for >>> >>> http://purl.org/vso/ns#bodyStyle >>> >>> You can use >>> >>> http://dbpedia.org/resource/Convertible >>> http://dbpedia.org/resource/Hatchback >>> http://dbpedia.org/resource/Station_wagon >>> http://dbpedia.org/resource/Sport_utility_vehicle >>> http://dbpedia.org/resource/Roadster >>> >>> as a value for that property, in statements like >>> >>> foo:myCar vso:bodyStyle . >>> >>> An OWL/RDF reasoner will infer then that >>> >>> rdf:type vso:BodyStyleValue >>> >>> which is perfectly fine. >>> >>> Hope that helps! >>> >>> Best >>> Martin >>> >>> >>> >>>> >>>> >>>> Best, >>>> >>>> fps >>>> _______________________________________________ >>>> goodrelations mailing list >>>> goodrelations at ebusiness-unibw.org >>>> http://ebusiness-unibw.org/cgi-bin/mailman/listinfo/goodrelations >>> >>> >>> >>> -------------------------------------------------------- >>> 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 Main Page: http://purl.org/goodrelations/ >>> >>> >>> >> >> >> _______________________________________________ >> goodrelations mailing list >> goodrelations at ebusiness-unibw.org >> http://ebusiness-unibw.org/cgi-bin/mailman/listinfo/goodrelations > > -------------------------------------------------------- > 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 Main Page: http://purl.org/goodrelations/ > > From martin.hepp at ebusiness-unibw.org Thu Jan 31 10:59:48 2013 From: martin.hepp at ebusiness-unibw.org (Martin Hepp) Date: Thu, 31 Jan 2013 10:59:48 +0100 Subject: [goodrelations] GoodRelations Extension for OpenCart Message-ID: <9D15D247-FAF9-4959-A09D-91C358B8B60C@ebusiness-unibw.org> Dear all: I just saw that there seems to be a new, free extension for adding GoodRelations to the OpenCart package: http://www.opencart.com/index.php?route=extension/extension/info&extension_id=10192 So far, I did not have the time to check the quality of the implementation, so this message should not be regarded as an endorsement. If anybody is using this extension, I would be happy to get the URI of the respective shop. Best wishes Martin Hepp -------------------------------------------------------- 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 Main Page: http://purl.org/goodrelations/