- From: Bijan Parsia <bparsia@isr.umd.edu>
- Date: Wed, 28 Jul 2004 23:25:39 -0400
- To: public-sws-ig <public-sws-ig@w3.org>
On Jul 28, 2004, at 11:14 PM, David Martin wrote: > Matthew R Bogner wrote: > >> Juergen, >> In case you are looking for a specific suggestion, I would suggest >> rereading this specific part of the technical walk through of OWL-S, >> (http://www.daml.org/services/owl-s/1.0/owl-s.html#Attributes). I >> could imagine that you might like to put together something like this >> into your profile ontology. >> <profile:serviceParameter> >> <addParam:Computations rdf:ID="#OtherComputationProblems"> >> <profile:serviceParameterName>Additional Computation >> Problems</profile:serviceParameterName> >> <profile:sParameter >> rdf:resource="&concepts;#OtherGAMSproblems" /> >> </addParam:Computations> >> </profile:serviceParameter> >> Hopefully someone can correct me if I'm wrong or misinterpreted the >> example. Have a look at the BravoAirProfile.owl file in the >> examples section for a good example of how they use the >> serviceParameter property in relation to the GeographicRadius >> example. > > An alternative to using serviceParameter, which I personally think is > preferable in many situations, is to create a subclass of Profile > (e.g. MathServiceProfile), and then define whatever properties you > like for that subclass (e.g., algorithm, taxonomicReference). This > approach is described and illusrated (simply) under Profile Hierarchy > on the examples page: > http://www.daml.org/services/owl-s/1.1B/examples.html Of course, there is no need to define a *subclass* before adding additional properties. Just use the properties (with, perhaps, a declaration of ObjectProperty or DatatypeProperty to stay in OWL DL). Indeed, it's often a good methodology to work from a propertycentric view and define the appropriate classes later. Cheers, Bijan Parsia.
Received on Wednesday, 28 July 2004 23:27:20 UTC