Proposed Changes to Profile.daml (0.9)

People,
             I'm soliciting comments on the following proposed changes to
the DAML-S Proposal (V0.9).



I've taken a look at the Profile, and have made some recommended changes.
Significantly, I've pruned down the Profile (based on various comments made
from discussions at the DAML-PI meeting, the SWSI meeting and tonights
telecom) and moved some concepts to additional files.



1) Profile-additionalParameters.daml

I've removed the example profile classes (listed below) and placed them in
their own file.

I'm not wedded to the name (Profile-additionalParameters.daml) so if people
want this changing, that is fine.  We should still offer these class
definitions, both as examples of how parts of the profile ontology can be
used, such as serviceParameters, and serviceCategories, and as useful
concepts in their own right.  However, as these do not define the core
ontology (rather, they support it), they have been abstracted.

            NAICS

            UNSPSC

            MaxResponseTime

            AverageResponseTime

            GeographicRadius

            DAndBRating



2) Profile-Depreciated-elements.daml

I've removed the deprecated properties (from 0.7) and just put them in a
file.

I haven't gone through this file to ensure validity; in fact we might want
to turn this file into a document, as it serves more as a reference doc
(listing deprecated functions and their meaning) and shouldn't be redefined
in a new namespace.  Remember that we are not removing the erlier ontology
versions, so these properties



3) Actor-defaultProperties.daml

I've moved the properties of the Actor class into their own file.  At the
ISWC F2F I was asked why we defined our own Actor class when there are
several other "person" type classes.  This is a good question!!!

So by moving the properties to a separate file, we only define the class
"Actor" in the Profile as a subclass of thing, and say no more about it.  If
people wish to use the original Actor properties, then this can be achieved
simply by including Actor-defaultProperties.daml, which extends the "Actor"
class with the additional properties.  From a reasoner's perspective, this
situation would be no different from that of 0.7.  However, if one chooses
to use another ontology (e.f. FOAF or vCard, or define their own), then the
mapping can be achieved by defining a sameClassAs relationship between the
Actor class and the new class.



There may be other implications of this, e.g. different definitions of Actor
in different profiles which then are registered in the same Matchmaker, so
feedback would be appreciated.  But I suspect that these implications could
occur anyway, and may be more problematic if we assert the Actor properties
in the Profile ontology.



4) Profile.daml

There are a couple of small cosmetic changes, such as changing any remaining
rdfs constructs to daml constructs, updating the change log, etc.





If people are happy with the suggestions, then I suggest we migrate the new
files to the release site and I will provide additional documentation
describing the changes, as well as examples that illustrate how the Actor
usage can be modified.  Additionally, small changes may be needed with our
0.9 examples.  Again, I'll assume responsibility for this.



            Terry


_______________________________________________________________________
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