Re: DAML-S: Services upper ontology cardinalities

David Martin wrote:

To illustrate these ideas (copied below), I've posted a simple class relationship
diagram here:

http://www.daml.org/services/daml-s/scratch/Services-upper.gif

I should say that I don't think getting these cardinalities just right is of great
importance, and that's consistent I think with what was discussed this morning in
the telecon.  Mark made the point that unless we're entirely certain about one of
these cardinality restrictions, it would be wise to leave it under constrained,
and I'm in accord with that.  But on the other hand, if we *are* certain about any
of them, I think that specifying those ones can help make our thinking clear to
users of DAML-S (and such specifications can potentially be used by tools).

-- David

>
> -------- Original Message --------
> Subject: DAML-S: Services upper ontology cardinalities
> Date: Mon, 13 May 2002 15:13:08 -0700
> From: David Martin <martin@ai.sri.com>
> Organization: SRI International
> To: www-ws@w3.org
>
> 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 Tuesday, 14 May 2002 16:07:40 UTC