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

Daniel -

I have a couple comments to add to Terry's (see earlier message in this
thread for Terry's comments).

Daniel Elenius wrote:

> Hi list.
>
> I am about to start describing some devices using DAML+OIL and/or
> DAML-S. These will include a printer, a wall-mounted presentation
> screen, etc, and it's all just for a simulation of what can be done with
> semantic service discovery. (This will be integrated with JXTA).
>
> Suppose I have different printers, and I want clients to be able to pick
> one that best fulfills some desired properties, like color or b/w,
> resolution, distance from client, OH capability, etc. Clients must also
> be able to find out how to actually use the printer's services, which
> could be just a print() method with lots of parameters for the desired
> printer settings, or some set_whatever() methods to set the printer's
> operating parameters. (I don't worry about the printer sending back
> asynchronous notifications at this time).
>
> I intend to use DAML+OIL to describe the printer's properties, and
> DAML-S to describe it's services (with a WSDL grounding and SOAP for the
> RPCs).
>
> The question is: Where do I put the description of the printer's
> properties?

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.

> In the DAML-S Profile file, or in a separate DAML+OIL file
> (for a total of five DAML+OIL files: The DAML-S Grounding, Profile,
> Process and Service files, plus the DAML+OIL property descriptions file).
>
> Is it a requirement to put all the DAML-S stuff into different files? It
>   could be handy to put it all in one file for very simple services
> perhaps...

No. there isn't such a requirement.

Regards,
David Martin

>
>
> /daniel

Received on Sunday, 23 February 2003 10:13:01 UTC