DAML-S: Services upper ontology cardinalities

Folks --

For the next (incremental) release (0.7) of DAML-S, I hope to get in
some refinements of our "upper ontology" (that is, the relationships
between the fundamental classes Service, Process, Profile, and
Grounding).

[Note to readers of this list who may not yet be familiar with DAML-S:
the current release is available at
http://www.DAML.org/services/daml-s/2001/10/.)

We've had some discussion about whether to eliminate the Service class
altogether -- but I'm not addressing that here.  (Currently my
thinking is not to eliminate it, but I plan to address that in a
separate message.)  But I think the questions in this message can be
considered more or less independently of that issue.

Comments requested!

-- David

-------------------------------

Services upper ontology: proposals regarding cardinalities

Profiles
--------

A service can have zero or more profiles.  We allow zero because there
may well be cases of services that don't get advertised, or aren't
meant to be searched for.  For example, this could be the case when a
service is shared among a small, fixed group of participants and is
never publicized "at large" on the Web.  We allow more than one
profile because it may well make sense to publicize the same service
within several different advertising contexts, or within several
different taxonomies of service advertisements.

Can a profile represent multiple different services (that is,
different in ways that aren't relevant for matchmaking purposes)?  My
proposed answer is "no".  My main reason is because our profiles tend
to be very complete (that is, they include specifics about what
company provides the service, geographic region if relevant, etc.) and
thus it would be unusual for a profile to represent multiple services
in a meaningful way.  Putting that another way -- essentially
everything about a service *is* potentially relevant for matchmaking
purposes.

Processes
---------

A service can have zero or 1 processes.  0 is allowed because there
may be services that want to advertise (and thus want to create a
profile), but don't actually have online access.  Multiple processes
*aren't* allowed because that creates a minefield of potential
mistakes and confusion.

Can a process describe multiple different services?  My answer is:
"definitely, yes ".  In my mind, this is similar to saying that a
well-written Java (or other programming language) function can be
reused by many different applications.  Technically, at least, it
should be possible for Amazon and Barnes & Noble to use the same
process to sell books.

Groundings
----------

Must an atomic process have a Grounding? I'm not clear yet on this.
If an atomic process can only represent something callable online,
then it makes sense to require a grounding.  But what if we want to
have processes that represent things happening off line?  For
instance, what if a real estate purchase process involves a step where
the mortgage broker gets preliminary approval from the lending
institution, and that can take place by sending a fax, or even placing
a phone call.  Might we want to represent this non-electronic
interaction using an atomic process?

--> In general, this strikes made as a large and fundamental question
-- should we allow for "seamless" representation of process elements
that happen online and offline, and if so, can we do so with our
existing process elements?

An atomic process can have multiple Groundings. A definite "yes".
Each grounding could represent a different network address and/or
protocol by which the same service is accessed.

A Grounding represents exactly 1 atomic process.  It must be this way,
since each grounding contains very specific information like network
addresses, and message details, which can only be meant for one
particular process.

Received on Monday, 13 May 2002 18:07:57 UTC