W3C home > Mailing lists > Public > www-ws@w3.org > February 2003

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

From: Terry R. Payne <trp@ecs.soton.ac.uk>
Date: Wed, 19 Feb 2003 19:54:19 -0000
To: "'Daniel Elenius'" <danel698@student.liu.se>
Cc: <www-ws@w3.org>
Message-ID: <037a01c2d850$b1182c90$3e404e98@ecs.soton.ac.uk>

Daniel,
	The problem here is that ideally you would want to describe your
services at an interface level (i.e. using IOPEs).  Whilst you should
probably be able to achieve this for some categories of devices, it may
not be as straightforward (as you've pointed out) to differentiate
between similar devices (e.g. colour and B/W printers that take
PostScript files).  One approach would be to define accompanying
reference ontologies so that the IOPEs are expressive enough to
differentiate between the results of similar devices.  However, this is
not always possible, and certainly doesn't solve the problem of
differentiating between the laserjet on this floor and another on the
floor below!!!

You could make use of two other non-functional properties:
serviceCategories and serviceParameters [1,2].  The former could be used
to differentiate between broad categories of devices.  The latter can be
used to define additional parameters that could be used to augment the
expressivity of a profile.  Such parameters may be used, for example,
when a service consumer is attempting to select an appropriate service
from a set of candidates that match a query (i.e. "so which printer
should I use from this list").

As far as splitting the DAML content - it is up to you.  There is no
reason why you should not collate all the descriptions in one file, or
split them across several files (this *is* based on a distributed
ontological framework afterall!!!).  However, if you fragment single
models across several files, then be aware how resource URIs are
resolved and how the import construct is interpreted.

	Terry

[1] http://www.daml.org/services/daml-s/0.7/
[2] http://www.daml.ecs.soton.ac.uk/notes/DAML-S0.7DraftPrimer.ppt


_______________________________________________________________________
Terry R. Payne, PhD.      | http://www.ecs.soton.ac.uk/~trp/index.html
University of Southampton | Voice: +44(0)23 8059 8343 [Fax: 8059 2865]
Southampton, SO17 1BJ, UK | Email: terry@acm.org / trp@ecs.soton.ac.uk




> -----Original Message-----
> From: www-ws-request@w3.org [mailto:www-ws-request@w3.org] On Behalf
Of
> Daniel Elenius
> Sent: 19 February 2003 15:19
> To: www-ws@w3.org
> Subject: Device/service descriptions in DAML-S and/or DAML+OIL
> 
> 
> 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? 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...
> 
> 
> /daniel
Received on Wednesday, 19 February 2003 14:54:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:41 GMT