Re: Device/service descriptions in DAML-S and/or DAML+OIL

>
>
>It sounds like your desired use of the printer properties is very much in
>line with the intended uses of the DAML-S profile.  In my view, the ideal
>approach would be to extend the DAML-S profile, simply by subclassing it and
>adding your properties.  The subclass of Profile might be called, say,
>PrinterProfile.  Look here:
>
>http://www.daml.org/services/daml-s/0.7/ProfileHierarchy.daml
>
>for 2 simple examples of such subclasses.  In the future, when there's a more
>comprehensive and widely accepted hierarchy of DAML-S profiles, printers
>might be subclassed several levels down (say, perhaps Profile ->
>DeviceProfile -> ElectronicDeviceProfile -> ComputingDeviceProfile ->
>ComputingPeripheralProfile -> PrinterProfile).  If all that existed, then it
>might make sense for you to integrate your properties into that hierarchy.
>But for now, since none of that exists, you can use whatever simple approach
>works well for your application.
>  
>
Right. That much I got. Should there also be a hierarchy of process 
models, groundings, and services, or is that implied somehow? Are you 
envisioning that profiles would be 'standardised' in some global 
ontology hierarchy, so that e.g. all printers would instantiate the
DeviceProfile -> ElectronicDeviceProfile -> ComputingDeviceProfile 
->ComputingPeripheralProfile -> PrinterProfile
?
And what about process models? I suppose it is easier to define 
hierarchies for "things" than for "processes". In the case of the 
BravoAir example, it refers to other ontologies defining "things" like 
airports, etc, and I suppose these "external" ontologies that are used 
would be in some sort of hierarchy that, ideally, would be globally 
understood and standardised.

Another thing: Suppose we have two different printers that instantiate 
the same printer profile. They have different values for some 
ServiceParameters defined in the printer profile. They have completely 
different process models (different RPCs to achieve the same "effect"). 
Is the goal to
1) Standardize interfaces (process models & groundings) so that any 
printer-using client would have the function calls in place to begin with
or
2) Have the client examine the process model and grounding in great 
detail, use some AI, and build its own RPC calls and UI if required?

I suppose the answer is "both". Is there anything I can read on (2)?

regards
Daniel

Received on Sunday, 23 February 2003 14:01:19 UTC