|
|
Index
0.
Prerequisites
1. How to use the Matchmaker
1.1 Create Advertisement
1.2 Load Advertisement
1.3 Create Request
1.4 Load Request
1.5 Browse Advertisement
1.6 Remove Advertisement
1.7 Matchamaker Control
2. How to use Sample Services
2.1 Services and Ontology for Vehicle Quoting
Service
2.2 Services and Ontology for Parts Quoting Service
2.3 Sample Services and Ontology for Toys Quoting
Service
Appendix.
Matchmaking Mechanism
A.1 Matchmaker Archtecture with UDDI Registry
A.2 Matchmaking Engine
A.3 Parsers Diagram
To fully
utilize this Matchmaking engine, you should know about the following
topics in advance.
- DAMLS
- A
DAML-based Web Services Description Language
- DAML+OIL
- A
Description Logic for DAML-based Ontology
- RuleML
(if you want to use constraints)
- A
Rule Markup Language based on RDF
After understanding
the prerequisites, it's easy to learn how to use this Matchmaker.
You need to know only two functions: the advertisement and the
request. Basically, the advertisement is the registration of
a service to our database, and the request is a search of the
database to find a matching service.
With
this Matchmaker, we provide two ways for each function: Create
and Submit, and Load and Submit, respectively.
Here you
can create a new DAMLS Profile description as an advertisement,
even if you don't know much about the DAMLS Profile. Please
provide the following information which will compose your own
service. Note that marks(*) are mandatory
fields.
Each
field name is identical to a DAML class or property in DAMLS
Profile. If you want to know definitions of those field,
please click the field name at Create Advertisement.
Also, to see an actual service example, please click "Show
Sample" button at the upper left corner.
Bussiness Information |
provider* |
Name of service provider |
phone |
Telephone number |
email |
Email address |
physicalAddress |
Postal address in free format |
webURL |
URL to the provider's web site |
Service Information |
serviceName* |
Name of this service |
textDescription |
Brief description of the service. It summarises what
the service offers, or to describe what service is requested.
|
|
Inputs |
|
parameterName* |
Name of parameter |
restrictedTo* |
Type of parameter, i.e., any kind of DAML+OIL class
(Thing) |
refersTo |
Reference to DAMLS Process Model |
constrainedBy |
References to constraints on this parameter, i.e.,
any kind of RuleML rule. To put more than one rules to
a parameter, type them in this field with separators ";".
|
|
Outputs |
|
parameterName* |
Name of parameter |
restrictedTo* |
Type of parameter, i.e., any kind of DAML+OIL class
(Thing) |
refersTo |
Reference to DAMLS
Process Model |
constrainedBy |
References to constraints on this parameter, i.e.,
any kind of RuleML rule. To put more than one rules to
a parameter, type them in this field with separators ";".
|
|
Preconditions |
|
parameterName |
Name of condition |
restrictedTo |
Reference to the actual condition description in any
rule language. Note that this is for service planner,
and the Matchmaker does not use this information. |
refersTo |
Reference to DAMLS
Process Model |
|
Effects |
|
parameterName |
Name of condition |
restrictedTo |
Reference to the actual condition description in any
rule language. Note that this is for service planner,
and the Matchmaker does not use this information. |
refersTo |
Reference to DAMLS Process Model |
|
Attributes |
|
geographicRadius |
One of attributes of this service. Select a country
from Country.daml.
|
Contact Information |
Submitter Email* |
Email address of submitter. Please keep it to remove
this advertisement. |
This is an
another way to submit an advertisement. If you already have
your service description, you can just load it, or copy and
paste it in the text area. You can see an example by pushing
"Show Sample" button as well. The marked(*)
fields are mandatory.
DAML-S Profile* |
DAML Service Profile description |
Submitter Email *
|
Email address of submitter. Please keep it to remove
this advertisement. |
In Create
Request, necessary information is almost the same as the
above Create Advertisement. However, you don't need to
specify Bussiness Information and Contact Information because
the matchmaking process will be done only by Service Information.
Also,
you can specify your own strategy of the service request in
the Matchmaker Control panel. Please look at Matchmaker
Control section below.
In Load
Request, the necessary information is almost the same as
the above Load Advertisement. However, you don't need
to specify Bussiness Information and Contact Information because
the matchmaking process will be done only by Service Information.
Also,
you can specify your own strategy of the service request in
the Matchmaker Control panel. Please look at Matchmaker
Control section below.
In addtion
to the above advertisement and request, you can look at the
list of all the registered advertisements in Browse Advertisement.
It also provides a simple keyword search. If you enter a word
in serviceName field, only the advertisements whose name has
the word (case sensitive) will be returned.
serviceName |
Portion of service name |
Remove your
advertisements here. You need to provide the submitter's email
address you entered in the advertisement, as well as the exact
same serviceName you entered. You can confirm the deletion on
the above Browse Advertisement.
serviceName* |
Name of service. |
Submitter Email* |
Email address of submitter. |
In the Matchmaker
Control panel of Create Request and Load Request,
you can specify the strategy of your service matching.
Here
we briefly explain each filter. For further detail, please
look at the Publications
page.
- Namespace
Filter
- Pre-checking
filter which determines whether or not two services have
at least one shared namespace (pointer to an ontology).
If no common ontology, those two services would have high
possibility of no relationship. The default is on.
- Text
Filter
- Pre-checking
filter for human-readable service explanation parts such
as comment and textDescriptions. It utilizes the well-known
IR (Infomation Retrieval) technique called TF/IDF (Term
Frequency Inverse Document Frequency) method. The default
is off.
- Similarity
Filter
- A
filter for inputs and outputs. It's relatively similar to
the next IO Type Filter. The main difference is that this
filter is more relaxed and encompasses all the classes within
the specified distance. The default is off.
- IO
Type Filter
- One
of the most important filters for inputs and outputs. In
DAML Services, types of inputs and outputs are defined as
DAML+OIL ontology classes instead of as XML Datatypes in
WSDL. This is like a method call by objects in Java instead
of primitive types like boolean, int, String, etc. This
filter basically determines whether inputs of a requested
service description can be subsumed by inputs of an advertisement,
and whether outputs of the advertisement can be subsumed
by outputs of the requested service description. The default
is on.
- Constraint
Filter
- Another
most important filter for constraints of inputs and outputs
(if any). As well as the above subsumption determination
for input and output types, the subsumption relationship
for each of the constraints are logically determined in
this filter. The default is on.
Consider Limit |
Max number of advertisements to be considered (inputted)
at each filter (Infinite | Limit). |
Accept Limit |
Max number of advertisement to be accepted (outputted)
at each filter (Infinite | Limit). |
Return Limit |
Max number of the result to be returned from this Matchmaker
(Infinite | Limit). |
Filter Selection |
Check the filter you want to use (Namespace | Text
| Similarity | IO Type | Constraint). Each filter will
be applied in this order. |
Text TF/IDF Threshold |
Threshold of cosin angle of TF/IDF vectors at Text
filter (default=0.2). |
Similarity Scope |
Distance to be searched in ontology tree at Similarity
filter (Infinite | Limit). |
Subsumption Scope |
Distance to be searched in ontology tree at Subsumption
filter and Constraint filter (Infinite | Limit). |
Subsumption Mode |
Direction to be searched in ontology tree at Subsumption
filter and Constraint filter (Exact | Plug-In | Relax).
Plug-In means the ontology tree will be searched in the
downward direction; that is, the subsumption relationship
will be determined. Relax means the ontology tree will
be searched in a downward and upward direction; that is,
the subsumption relationship or the close relationship,
but not subsumption, will be determined. "Exact"
determines whether two classes are equivalent or not.
|
We also provide
three examples of Web Services for reference purposes. Please
look at the following sections.
To try
to use them; go to Sample Services
and click one of them. You will see the actual DAMLS Profile
desription. Select "view source" command of your browser and
copy all the text that appears on your desktop. Then, go back
to Load Advertisement or Load Request, and paste
it to the text area. Don't forget to put your submitter's
email address before submission.
This is the
simplest one, for vehicle quoting service. Each service here
is a single shot, and no transaction. Therefore, we don't describe
any DAMLS Process Model for this example (it would be an atomic
process, anyway). Also, an input of each service is just a class
of vehicle ontology which means description of a type of vehicle,
and an output is a quoted price.
Please
see this figure
for the concept of the example.
Related
files are:
Quoting Service
for Vehicle
Quoting Service for
Car
Quoting Service for
Bus
Quoting Service for
Sedan
Quoting Service for
Ginger
Quoting Service for
Dog
Quoting Service
for Car in Japan
Quoting Service
for Car made by GM
Quoting Service
for Car made by Isuzu
Simple Ontology for Car
Simple Ontology for Car Makers
Simple Ontology for Animal
Mathematical Ontology
Sample Rules
Examples
of industrial parts quoting service. The basic concept is similar
to the above one, but it utilizes some more constraints (RuleML
rules) on inputs and outputs.
Please
see this figure
for the concept of the example and logical form of those rules.
Related
files are:
Quoting Service for
Parts1
Quoting Service for
Parts2
Quoting Service for
PartsA
Quoting Service for
PartsB
Quoting Service for
PartsC
Quoting Service for
PartsD
Quoting Service for
PartsE
Simple Ontology for Industrial Parts
Simple Ontology for Parts
Makers
Mathematical Ontology
Sample Rules
Example of
toys quoting service. It illustrates the relationship between
Restriction properties of DAML classes and constraints (RuleML
rules) on those classes. You can find the same thing described
in both formats.
Related
files are:
Quoting Service for
Toy1
Quoting Service for
Toy2
Simple Ontology for Toys
For users'
better understainding, we briefly provide the internal mechanizm
of this Matchmaker. Please look at Publications
page for further information.
Matchmaker
has been developed as an additional search function to UDDI
Registry. It provide semantics service matching based on inputs,
outputs, constraints, and other attributes, which are currently
described in DAMLS Profile (but, WSDL is also in our scope).
In DAMLS Profile, ontology is described in DAML+OIL and rules
are described in RuleML. Firstly, advertisements are parsed
and stored in UDDI Registry at CMU through the Matchmaker. Then,
when a request comes, the Matchmaker retrives similar advertisements
and collect the entire information of those advertisements from
UDDI Registry.
Please
refer to this figure for the Matchmaker
archtecture with UDDI Registry.
Matchmaking
engine has a filter approach which is adjustable for defferent
needs for each search and trade-off of speed and accuracy.
Please
refer to this figure
for the matchmaking engine archtecture.
Here we also
provide the architecture of Parsers
Diagram.
|
|