Re: DAML-S: ObjectProperty vs ServiceParameters

Oh, because ObjectProperties are *properties* of the profile, and thus 
retained on subclassing, whereas the ServiceCategory instances are just 
classes that will not retain a connection to the new subclassed Profile? 
What about the serviceParameter property, defined in Profile.daml as:


<!--
	serviceParameters - An expandable list of properties that
	may accompany a profile description.

	The range of each property is unconstrained, i.e. no range restrictions
	are placed on the service parameters at present. Specific service
	parameters will specialise this property by restricting the range
	appropriately and using subPropertyOf.
     -->

   <daml:Property rdf:ID="serviceParameter">
     <daml:domain rdf:resource="#Profile"/>
     <daml:range rdf:resource="#ServiceParameter"/>
   </daml:Property>



I'm not too good at this stuff yet, so correct me if I'm wrong, but 
wouldn't this let me define a serviceParameter (small s) property of a 
Profile that connects a ServiceParameter (capital S) class to the 
profile class? And since it's a property, it will retain its connection 
to the new subclassed profile?


regards
/Daniel



David Martin wrote:
> Daniel Elenius wrote:
> 
> 
>>I am looking at ProfileHierarchy.daml, and I see that DAML+OIL
>>ObjectProperty has been used to define properties of the example classes
>>defined there. For example, Information_Service has "source", "topic"
>>and "information_date" ObjectProperties. Shouldn't the more specific
>>DAML-S ServiceParameter be used here?
> 
> 
> Both approaches are valid.  Subclassing of  ObjectProperty is especially
> appropriate when constructing a hierarchy of profiles - it allows for the
> most direct use of DAML+OIL's facilities for property subclassing.
> However, as noted in
> http://www.daml.org/services/daml-s/0.7/ProfileHierarchy.html,
> last paragraph, we recognize that for some situations, it may be preferred
> to create a "flat" (non-hierarchical) organization of profiles.  I believe
> ServiceParameter may be more useful in the flat approach.
> 
> Others may wish to comment further on the use of ServiceParameter.
> 
> Regards,
> David Martin
> 
>

Received on Tuesday, 25 February 2003 04:00:55 UTC