RE: Proposed Changes to Profile.daml (0.9)

David,
    No problem.  The file name changes would be fine - it is easy enough to
propagate these changes on the daml-s site.

    Terry

  -----Original Message-----
  From: David Martin [mailto:martin@ai.sri.com]
  Sent: Wednesday, May 21, 2003 7:19 AM
  To: Terry R. Payne
  Cc: www-ws@w3.org
  Subject: Re: Proposed Changes to Profile.daml (0.9)


  Terry -
  Thanks for taking the lead on these changes.  I agree these are
substantial improvements, and it's fine with me to get them into 0.9.

  I'd still like to get more clear about the motivation for the
serviceParameter property; perhaps we can discuss this tomorrow.  But that
probably doesn't affect your proposed changes, so let's go ahead and move
forward with your changes.

  My only comments are regarding file names.  We sort of have a naming
convention.  That is, both for identifiers and for filenames, I've been
avoiding hyphens and underscores and relying on capitalization.  So, how
would you feel about these:

  ProfileAdditionalParameters.daml

  ProfileDeprecatedElements.daml
  ActorDefaultProperties.daml
  Cheers, David

  "Terry R. Payne" wrote:

    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