Re: [DAML-S] About grounding of services

Saied Tazari wrote:

> Hi,
>
> [[Some may say it is too late for such comments but I think the following is
> a serious contribution.]]
>
> Is it right that a concrete SW component may provide several services?  In
> my opinion, yes! (e.g.
> http://www.daml.org/services/daml-s/0.9/Service.daml#provides has no
> cardinality restrictions)

Thanks for your comments.

I certainly agree that a SW component may provide several Services.  But I should
point out, by way of clarification, the domain of the DAML-S "provides" property
is "rdfs:Resource", which doesn't necessarily indicate a concrete SW component.
We've never made it precisely clear what kind of "resource" "provides" a service -
and I don't think it's terribly important that we do make it clear.  The original
idea was just to be able to associate a service with some web site that hosts the
service.

> Is that right that service groundings are supported by concrete SW
> components and not by the service itself?  In my opinion, yes!

I get the impression you're trying to ensure that the term "supports" is used
correctly; that is, the use is consistent with English usage.   If so, I'm
somewhat sympathetic.  That is, I agree perhaps the word "support" isn't a perfect
choice to indicate the relationship between a Service and one of its groundings.
However, I'd be more inclined just to change the name of the property, rather than
introduce SWComponent into the ontology, as you  propose below.  I don't think
there's any need to refer to the concrete software components that implement the
Services.  In fact, I think it goes against the spirit of Web services.  That is,
the concrete software components should be invisible; those are private,
system-specific implementation details that users of the service don't need to
know about.

Also, the purpose of the service profile is largely to support the construction of
advertisements for a service - and I think it's clear you might want to have
multiple different advertisements for the same service.  Therefore, I don't think
it's helpful to merge ServiceProfile with Service.

Regards,
David Martin

> If we accept my answers to the above questions, it seems to me that we'd
> better to add a new class called SWComponent (or ServiceProvider if it isn't
> confusing) that provides as many services as it likes, merge ServiceProfile
> and Service into one class called Service, and eliminate the properties
> 'presentedBy' and 'presents'.  Then, we must redefine 'supports' with
> SWComponent as its domain and ServiceGrounding as its range and add a new
> property called theService/binds/enacts/utilizes/employs with
> ServiceGrounding as its domain and Service as its range.  The attached class
> diagram summarizes this idea putting aside many details, such as classes
> modeling the information about the code base of SWComponent and access rights.
>
> I appreciate your comments in advance.
>
> Regards,
>
> -- Saied Tazari
>
> P.S. This idea and the attached diagram is part of a publication to be
> submitted to SWDB (http://swdb.semanticweb.org).  I disclosed it to this
> group only as a contribution to DAML-S discussions.
>
>   ------------------------------------------------------------------------
>  [Image]

Received on Thursday, 22 May 2003 02:00:44 UTC