- 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>
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 UTC