W3C home > Mailing lists > Public > www-webont-wg@w3.org > July 2003

Re: Proposed response to Ken Laskey

From: Jim Hendler <hendler@cs.umd.edu>
Date: Fri, 18 Jul 2003 10:31:33 -0400
Message-Id: <p05200f8fbb3db48794b9@[10.0.1.3]>
To: Jeff Heflin <heflin@cse.lehigh.edu>
Cc: webont <www-webont-wg@w3.org>

At 10:20 AM -0400 7/18/03, Jeff Heflin wrote:
>Jim,
>
>This seems fine to me, but I have to minor points:
>
>1) You should probably change "We do not believe the Use Cases and
>Requirements is the right place for the discussion you desire." to
>"We do not believe the body of the Use Cases and Requirements is the
>right place for the discussion you desire." since you have proposed that
>an appendix regarding this be added
>
>2) at the end of the message, change "Jeff" to "Jeff and Jim" (or "Jim
>and Jeff", I don't care)
>
>Jeff
>

good points - I'll make these changes.
  -JH



>Jim Hendler wrote:
>>
>>  Ken - as your comments mostly address the Requirements document, I
>>  asked Jeff Heflin, the editor, to write the response.  However, there
>>  were a couple of things where he felt the chair needed to be involved,
>>  so I've done some editing and am sending this - consider it a joint
>>  effort (but he did most of the work)
>>   please let us know if you'll accept this response - if not, please
>>  let us know which things in particular you feel we would need to
>>  change before you would feel comfortable with our moving to Candidate
>>  Recommendation.
>>  Jim H
>>
>>  Ken Laskey wrote:
>>  >
>>  > Jim,
>>  >
>>  > Thank you for your email of 9 June 2003 which responds to comments I
>>  > submitted during the OWL Last Call and my apologies for taking so
>>  long in
>>  > responding back.  As you noted, we had extensive discussions during
>>  the WWW
>>  > conference in Budapest and in consideration of those discussions, I
>>  would
>>  > like to make some specific suggestions beyond the more general
>>  nature of my
>>  > previous comments.  These suggestions, which currently focus on the
>>  use
>>  > cases,  address what I feel are gaps to which I alluded more
>>  generally in
>>  > my previous comments.  My intent in making these suggestions is to
>>  > establish a more complete context for the current OWL contributions
>>  and (as
>>  > my Ph.D. advisor always demanded) the significance of those
>>  contributions
>>  > in advancing the Semantic Web.
>>  Ken,
>>  We'd like to thank you for your thorough review and detailed
>>  suggestions.
>>
>>  > My suggestions also represent an evolution in the use cases from a
>>  set of
>>  > relevant challenges to a statement which includes how the current
>>  work
>>  > provides an enabler to eventual solutions.  I have found this useful
>>  in
>>  > other work because it maintains a clear connection between the
>>  initial
>>  > motivators and the current state of advancement.  Also, I believe
>>  this is
>>  > important because while the use cases are comprehensive in
>>  illustrating the
>>  > challenges, it is a disservice to give the impression that OWL in
>>  and of
>>  > itself will provide the solution.  Rather, OWL is seen as a critical
>>  > enabling technology and the distinct OWL contributions should be
>>  made clear.
>>  We do not believe the Use Cases and Requirements is the right place
>>  for
>>  the discussion you desire. To truly explain how OWL meets a particular
>>  requirement would require a detailed description of the relevant
>>  features, duplicating much material from other OWL documents. However,
>>  we
>>  can understand how the document might be read in such a way as to lead
>>  to a false impression of the intended capabilities of OWL. In some
>>  cases
>>  below, I suggest alternative wordings that should help prevent this
>>  confusion.
>>
>>  > The following are specific edits and additions which I propose:
>>  >
>>  > <original section="2"  paragraph="1">
>>  > Ontologies can be used to improve existing Web-based applications
>>  and may
>>  > enable new uses of the Web. In this section we describe six
>>  representative
>>  > use cases of Web ontologies. Note that this is not an exhaustive
>>  list, but
>>  > instead a cross-section of interesting use cases.
>>  > </original>
>>  >
>>  > <comment>
>>  > Add to the end of the paragraph:
>>  >
>>  > Also note that the present OWL charter bounds the scope to that
>>  necessary
>>  > to capture sufficient information to support reasoning applications
>>  but
>>  > does not in itself include the complete semantics required to
>>  capture
>>  > probablistic or conditional aspects which these use cases may imply.
>>  > </comment>
>>  Instead, we propose to add:
>>
>>  "These use cases served as a guideline in choosing requirements for
>>  the
>>  OWL language (see Section 4). The requirements were chosen based on
>>  the
>>  aspects of the use cases that the working group considered most
>>  important, while considering the scope of the OWL charter and other
>>  design constraints. As such, one should not assume that OWL will
>>  directly support every aspect of the use cases."
>>
>>  > <original section="2.1" paragraph="3">
>>  > Of course, such a technique relies on content providers annotating
>>  their
>>  > pages with the web ontology language, but if we assume that these
>>  owners
>>  > will try to distribute their content as widely as possible, then we
>>  can
>>  > expect that they would be willing to do this.
>>  > </original>
>>  >
>>  > <comment>
>>  > This is a questionable assumption because providers are notoriously
>>  bad at
>>  > creating useful metadata and thus I believe this undercuts your
>>  overall
>>  > argument.  Suggested alternate text:
>>  >
>>  > Such a technique relies on content providers using the Web ontology
>>  > language to capture high-quality ontology relationships, and an
>>  objective
>>  > of OWL is to enable sufficiently rich and useful metadata content to
>>  > motivate the necessary effort.  It is a separate challenge to
>>  minimize this
>>  > effort and an ontology language will likely have a greater impact if
>>  it can
>>  > facilitate metadata capture as an nonintrusive part of any
>>  information
>>  > creation process.
>>  > </comment>
>>  Okay, we will make this change.
>>
>>  > <original section="2.2" paragraph="3">
>>  > An example of such knowledge would be that a "Late Georgian chest of
>>  > drawers" is typically made of mahogany. This knowledge is crucial
>>  for real
>>  > semantic queries, e.g. a user query for "antique mahogany storage
>>  > furniture" could match with images of Late Georgian chests of
>>  drawers, even
>>  > if nothing is said about wood type in the image annotation.
>>  > </original>
>>  >
>>  > <comment>
>>  > OWL supports equivalence relationships but not probablistic
>>  relationships
>>  > such as "typically made of mahogany".  The concept "typically"would
>>  likely
>>  > be application-specific reasoning which might be supported by a
>>  value
>>  > mapping ontology, but this logic goes beyond OWL capabilities.
>>  Suggest
>>  > adding to the end of the paragraph:
>>  >
>>  > While OWL in its present form does not intrinsically support such
>>  > probablistic or conditional associations useful in real semantic
>>  queries,
>>  > application-specific semantics could be encoded in OWL to support
>>  such
>>  > functionality.
>>  > </comment>
>>
>>  Actually, the use case was talking about defeasible inheritance
>>  reasoning, not probability. Although probability can be clearly of use
>>  in some use cases, the working group did not consider it an important
>>  requirement, although support for probabilistic information is implied
>>  by Requirement R12. Attaching Information to Statements. However,  you
>>  are right that the "typically" is misleading here, and therefore we
>>  will change this to read
>>  "...a `Late Georgian chest of drawers', in the absence of other
>>  information, would be assumed to be `made of mahogany.'  This
>>  knowledge ... "
>>  which we agree will be less misleading.
>>
>>  > <original section="2.3" paragraph="1">
>>  > A single taxonomy is often limiting because many things can fall
>>  under
>>  > multiple categories.
>>  > </original>
>>  >
>>  > <comment>
>>  > The limitation of a single ontology is not in the possibility of
>>  multiple
>>  > categories (relevant multiple categories can coexist in a single
>>  ontology)
>>  > but that the categories included in any single ontology represent
>>  the view
>>  > which the ontology author needed to capture.  As a more accurate
>>  statement
>>  > of the problem, I suggest the following be substituted for the
>>  original:
>>  >
>>  > A single ontology is often limiting because the constituent
>>  categories are
>>  > likely constrained to those representing one view and one
>>  granularity of a
>>  > domain, and the ability to simultaneously work with multiple
>>  ontologies
>>  > increases the richness of description.
>>  > </comment>
>>  Good suggestion. We will make the change.
>>
>>  > <original section="2.3" paragraph="3">
>>  > A typical problem for each of these types of users is that they may
>>  not
>>  > share terminology with the authors of the desired content. The
>>  salesperson
>>  > may not know the technical name for a desired feature or technical
>>  people
>>  > in different fields might use different terms for the same concept.
>>  For
>>  > such problems, it would be useful for each class of user to have
>>  different
>>  > ontologies of terms, but have each ontology interrelated so
>>  translations
>>  > can be performed automatically.
>>  > </original>
>>  >
>>  > <comment>
>>  > In many situations, the usage of terminology within an ontology may
>>  not be
>>  > exact in existing data stores, and we need to leverage existing
>>  resources
>>  > rather than implying that these must be repairedto enable conclusive
>>  > translation.  To encompass this need, I suggest adding the following
>>  to the
>>  > end of the paragraph:
>>  >
>>  > OWL does not account for fuzzinessin the alignment of terms in
>>  different
>>  > vocabularies but it can capture sufficient usage examples to support
>>  > application-specific processing.
>>  > </comment>
>>  Given our revised statement to the opening of section 2 and the fact
>>  that
>>  fuzzy reasoning is not in the list of requirements, we'd prefer not to
>>  add such a statement.
>>
>>  > <original section="2.5" paragraph="2">
>>  > This type of agent requires domain ontologies that represent the
>>  terms for
>>  > restaurants, hotels, etc. and service ontologies to represent the
>>  terms
>>  > used in the actual services. When building the actual services, the
>>  > information may come from a number of sources, such as portals,
>>  > service-specific sites, reservation sites and the general Web.
>>  > </original>
>>  >
>>  > <comment>
>>  > The discussion of agents and services switches the focus a bit from
>>  > information to the applications.  A noncritical suggestion is to add
>>  the
>>  > following text at the end of the paragraph:
>>  >
>>  > For a service environment, an ontology language will enable
>>  information
>>  > capture necessary for applications to discriminate and balance among
>>  user
>>  > preferences.
>>  > </comment>
>>  We will change the paragraph to:
>>
>>  "This type of agent requires domain ontologies that represent the
>>  terms
>>  for
>>  restaurants, hotels, etc. and service ontologies to represent the
>>  terms
>>  used in the actual services. These ontologies will enable the capture
>>  of
>>  information necessary for applications to discriminate and balance
>>  among
>>  user preferences. Such information may be provided by a number of
>>  sources, such as portals, service-specific sites, reservation sites
>>  and
>>  the general Web."
>>
>>  >
>>  > <original section="2.6" paragraph="4">
>>  > The interoperation scenarios are dynamic in nature (i.e., devices
>>  appear
>>  > and disappear at any moment as their owners carry them from one room
>>  or
>>  > building to another) and do not involve humans in the loop as far as
>>  > (re-)configuration is concerned.
>>  >
>>  > Given that device functionality can be modeled as web services, the
>>  needs
>>  > for this use case are somewhat similar to the needs for DAML-S
>>  > (particularly the issues surrounding the expressiveness of the
>>  language).
>>  >
>>  > The tasks involved in the utilization of services involve discovery,
>>  > contracting, and composition. The contracting of services may
>>  involve
>>  > representing information about security, privacy and trust, as well
>>  as
>>  > about compensation-related details (the provider of a service may
>>  have to
>>  > be compensated for services rendered). In particular, it is a goal
>>  that
>>  > corporate or organizational security policies be expressed in
>>  > application-neutral form, thus enabling constraint representation
>>  across
>>  > the diversity of enforcement mechanisms (e.g., firewalls,
>>  filters/scanners,
>>  > traffic monitors, application-level routers and load-balancers).
>>  >
>>  > Given that RDF-based schemes for representing information about
>>  device
>>  > characteristics have started to be adopted (namely, W3C's Composite
>>  > Capability/Preference Profile (CC/PP) and WAP Forum's User Agent
>>  Profile or
>>  > UAProf), an additional need is compatibility with RDF at some level.
>>  > </original>
>>  >
>>  > <comment>
>>  > In reading paragraphs 4 through 7, paragraphs 5 and 7 feel like
>>  disjointed
>>  > inserts and do not provide significant context or motivation.  I
>>  suggest
>>  > combining paragraphs 4 and 6, and incorporating elements of
>>  paragraphs 5
>>  > and 7 to give the following:
>>  >
>>  > The interoperation scenarios are dynamic in nature (i.e., devices
>>  appear
>>  > and disappear at any moment as their owners carry them from one room
>>  or
>>  > building to another) and do not involve humans in the loop as far as
>>  > (re-)configuration is concerned. The tasks involved in the
>>  utilization of
>>  > services involve discovery, contracting, and composition. The
>>  contracting
>>  > of services may involve representing information about security,
>>  privacy
>>  > and trust, as well as about compensation-related details (the
>>  provider of a
>>  > service may have to be compensated for services rendered). In
>>  particular,
>>  > it is a goal that corporate or organizational security policies be
>>  > expressed in application-neutral form, thus enabling constraint
>>  > representation across the diversity of enforcement mechanisms (e.g.,
>>  > firewalls, filters/scanners, traffic monitors, application-level
>>  routers
>>  > and load-balancers).
>>  >
>>  > Thus, an ontology language will be used to describe the
>>  characteristics of
>>  > devices, the means of access to such devices, the policy established
>>  by the
>>  > owner for use of a device, and other technical constraints and
>>  requirements
>>  > that affect incorporating a device into a ubiquitous computing
>>  > network.  The needs established for DAML-S (particularly the issues
>>  > surrounding the expressiveness of the language) and the RDF-based
>>  schemes
>>  > for representing information about device characteristics (namely,
>>  W3C's
>>  > Composite Capability/Preference Profile (CC/PP) and WAP Forum's User
>>  Agent
>>  > Profile or UAProf) directly relate to this use case and the resource
>>  > infrastructure which will support applications which will negotiate
>>  and
>>  > dynamically configure ad hoc networks.
>>  > </comment>
>>  Excellent change. We will make it.
>>
>>  > <original section="3" paragraph="1">
>>  > Design goals describe general motivations for the language that do
>>  not
>>  > necessarily result from any single use case. In this section, we
>>  describe
>>  > eight design goals for the Web ontology language. For each goal, we
>>  > describe the tasks it supports and explain the rationale for the
>>  goal. We
>>  > also describe the degree to which RDF and RDF Schema supports the
>>  goal.
>>  > </original>
>>  >
>>  > <comment>
>>  > This comment generally relates to all subsections of Section 3.  The
>>  design
>>  > goals need to address what the Web language will contribute to a
>>  perceived
>>  > challenge and not just what the high-level challenge is.  Why is a
>>  > particular design goal important enough to include and what is OWLs
>>  > intended contribution to meeting the challenge?  To this end, I
>>  suggest
>>  > each design goal include a section for OWL approach and current
>>  > contributionbefore the RDF(S) Support.  This improves the
>>  description of
>>  > where we would like to be (the design goal), how far we had come
>>  (the
>>  > RDF(S) contribution so far), and how the present work (the OWL
>>  > contribution) moves us forward.  Note, in the interest of not
>>  delaying this
>>  > response further, I have not provided suggested text for each
>>  section but
>>  > would be willing to discuss details later.
>>  We agree that doing what you ask here would be a useful thing to have,
>>  but doing it right would go well beyond the scope of this requirements
>>  document (and will be the job of those who write the eventual OWL
>>  books).   However, it is the case that a way to track where each of
>>  our objectives and requirements are discussed in our documents would
>>  be useful.  During the CR period we will endeavor to produce this
>>  mapping and consider including it in as an Appendix to one of our
>>  documents.
>>
>>  > Additionally, the chosen design goals have an uneven connection
>>  between
>>  > them.  As a reader, I am looking for a common thread and the
>>  presentation
>>  > does not provide this.  I suggest the following replace the current
>>  paragraph:
>>  >
>>  > Design goals describe general motivations for the language that do
>>  not
>>  > necessarily result from any single use case. In this section, we
>>  describe
>>  > eight design goals for the Web ontology language, in particular
>>  those
>>  > dealing with
>>  > - using established ontologies
>>  > - changing established ontologies
>>  > - interacting established ontologies
>>  > - detecting inconsistencies across ontologies and instances of use
>>  > - providing a balance between expressivity and scalability when
>>  creating
>>  > ontologies
>>  > - avoiding unnecessary complexity which may discourage widespread
>>  adoption
>>  > - maintaining compatibility with other standards
>>  > - supporting internationalization
>>  > For each goal, we describe the tasks it supports and explain the
>>  rationale
>>  > for the goal. We also describe the OWL approach in advancing these
>>  goals
>>  > and the degree to which RDF and RDF Schema currently provides
>>  support.
>>  > </comment>
>>  This is a good idea, we'll accept it although slightly changing the
>>  wording to be more consistent with the remainder of our document:
>>
>>  "Design goals describe general motivations for the language that do
>>  not
>>  necessarily result from any single use case. Along with the use cases,
>>  these motivate the requirements and objectives in Sections 4 and 5. In
>>  this section, we describe eight design goals for the Web ontology
>>  language, in particular those dealing with:
>>   - using established ontologies
>>   - changing established ontologies
>>   - integrating established ontologies
>>   - detecting inconsistencies across ontologies and instances of use
>>   - providing a balance between expressivity and scalability when
>>  creating
>>   ontologies
>>   - avoiding unnecessary complexity which may discourage widespread
>>  adoption
>>   - maintaining compatibility with other standards
>>   - supporting internationalization
>>  For each goal, we describe the tasks it supports and explain the
>>  rationale for the goal. We also describe the degree to which RDF and
>>  RDF
>>  Schema supports the goal."
>>
>>  > <original section="3.1" paragraph="1">
>>  > Ontologies should be publicly available and different data sources
>>  should
>>  > be able to commit to the same ontology for shared meaning. Also,
>>  ontologies
>>  > should be able to extend other ontologies in order to provide
>>  additional
>>  > definitions.
>>  > </original>
>>  >
>>  > <comment>
>>  > In my suggested wording for Section 3, I more generally describe the
>>  focus
>>  > of this section as using established ontologies.  The current
>>  wording only
>>  > includes shared use of the same snapshot of an ontology or defining
>>  > ontology extensions, but general examples of use and extension
>>  quickly
>>  > require the sibling concepts of pruning/contraction, reorganization,
>>  and
>>  > combinations.  The need for versioning to track such changes is
>>  alluded to
>>  > in Section 3.2, but acknowledging these capabilities seems an
>>  obvious
>>  > omission here.  I suggest the following wording replace the
>>  original:
>>  >
>>  > Ontologies should be publicly available and different data sources
>>  should
>>  > be able to commit to the same ontology for shared meaning. To ensure
>>  the
>>  > maximum degree of semantic capture, support is needed to identify
>>  ontology
>>  > extensions to provide additional definitions, ontology
>>  reorganization to
>>  > modify the view of a domain without reinventing existing concepts,
>>  > combining multiple ontologies to allow higher level views to use
>>  more
>>  > detailed descriptions, and locally pruning shared ontologies to
>>  eliminate
>>  > overlap in combined ontologies or to reduce overhead in dealing with
>>  > ontology details that are not needed for the application at hand.
>>  > </comment>
>>  We think this is redundant with sections 3.2 and 3.3 and would prefer
>>  not to add it.
>>
>>  > <original section="3.4" paragraph="3">
>>  > Justification:
>>  > The Web is decentralized, allowing anyone to say anything. As a
>>  result,
>>  > different viewpoints may be contradictory, or even false information
>>  may be
>>  > provided. In order to prevent agents from combining incompatible
>>  data or
>>  > from taking consistent data and evolving it into an inconsistent
>>  state, it
>>  > is important that inconsistencies can be detected automatically.
>>  > </original>
>>  >
>>  > <comment>
>>  > Adding a section following this on the OWL contribution is
>>  especially
>>  > important because the solution space is not obvious.  The author
>>  examples
>>  > (Bucky Beaver or Penelope Ashe) I previously used may be a good
>>  basis for
>>  > discussion of how OWL would support detecting and responding to such
>>  > inconsistency.  It is an extremely important concept because it
>>  deals
>>  > directly with using Web resources as these exist (now and in the
>>  future)
>>  > and does not just put the onus on the resource owner to redo things
>>  > "correctly".
>>  > </comment>
>>
>>  The degree to which this design goal influenced our design can be
>>  discovered by looking at what requirements it motivated. In this case
>>  it
>>  is: R7. Class definition primitives, R8. Property definition
>>  primitives,
>>  and R14. Cardinality constraints. It also motivates objectives O3, O4,
>>  and O14.
>>
>>  > <original section="3.5" paragraph="3">
>>  > Justification:
>>  > There are over one billion pages on the Web, and the potential
>>  application
>>  > of the Semantic Web to embedded devices and agents poses even larger
>>  > amounts of information that must be handled. The web ontology
>>  language
>>  > should support reasoning systems that scale well. However, the
>>  language
>>  > should also be as expressive as possible, so that users can state
>>  the kinds
>>  > of knowledge that is important to their applications.
>>  > </original>
>>  >
>>  > <comment>
>>  > The first four design goals describe realproblems which this and the
>>  > following, while certainly as important, are less concrete
>>  situations.  An
>>  > OWL contribution section following the justification would be useful
>>  to
>>  > indicate how the OWL 1.0 spec is believed to have accomplished a
>>  reasonable
>>  > balance.  I understand OWL Lite, OWL DL, and OWL Full, but a few
>>  words here
>>  > would provide context and continuity.
>>  > </comment>
>>  As mentioned earlier, we do not believe the Requirements document is
>>  the
>>  right place for this discussion.  In particular, the intent of the
>>  overview document was to provide more of such discussion, and we think
>>  that it is addressed well there.  Thus, we'd prefer not to add this
>>  discussion again here.
>>
>>  > <original section="3.6" paragraph="3">
>>  > Justification:
>>  > Although ideally most users will be isolated from the language by
>>  front end
>>  > tools, the basic philosophy of the language must be natural and easy
>>  to
>>  > learn. Furthermore, early adopters, tool developers, and power users
>>  may
>>  > work directly with the syntax, meaning human readable (and writable)
>>  syntax
>>  > is desirable.
>>  > </original>
>>  >
>>  > <comment>
>>  > Much the same as I said for Section 3.5.  Something more germane to
>>  OWL is
>>  > needed rather than a general motherhood statement that ease of use
>>  is
>>  > good.  In addition, OWL will require a firmer grounding in the
>>  underlying
>>  > concepts than say did XML because for OWL the encoding of tag syntax
>>  is a
>>  > trivial problem compared with organizing ontology concepts in a
>>  > domain.  While tool support will be important, keeping the
>>  underlying
>>  > concepts accessible will be much more critical.
>>  > </comment>
>>
>>  The details of how we meet this objective are discussed in great
>>  detail throughout the guide and the overview document - thus, what we
>>  proposed above, tracking which requirements and objectives are handled
>>  where, should help with this.
>>
>>  > At this stage, I have not gone into detailed comments on OWL syntax
>>  because
>>  > I see no need to create further delay that would be introduced by
>>  > suggesting revisions of existing syntax and the associated
>>  implementations
>>  > to incorporate noncritical changes.  However, the one shortcoming
>>  that
>>  > seems to be easily addressed is in the area of disjoint classes.  In
>>  > section 5.3 of the OWL Language Guide, it notes that "the number of
>>  > disjointness assertions grows proportionally to n^2".  The rationale
>>  that
>>  > "n is typically small" is the sort that is often quickly proved
>>  wrong.  I
>>  > would suggest the addition of a mutallyDisjointWith syntax something
>>  like
>>  >
>>  >              <owl:mutuallyDisjointWith>
>>  >                          <owl:disjointClass rdf:resource=class1/>
>>  >                          <owl:disjointClass rdf:resource=class2/>
>>  >                          <owl:disjointClass rdf:resource=class3/>
>>  >                          <...>
>>  >              </owl:mutallyDisjointWith>
>>
>>  The working group did consider adding this in response to an earlier
>>  comment , but decided not to (see the reply Dan Connolly sent at
>>  [1]).  There are some syntax issues that make it difficult to express
>>  the way you propose above.  However, there is a workaorund where one
>>  does not need the N^2 statements, as described by Ian Horrocks in [2],
>>  and we will add a pointer to that to our issues list to make it
>>  clearer what to do when the number of classes is large.
>>
>>  > Again, I apologize for the delay in submitting this response but my
>>  > organization change has proven to be time consuming and I believe
>>  the
>>  > changes I propose here are consistent with the issues we have
>>  previously
>>  > discussed.  I would be open to discussing these further as would be
>>  useful.
>>
>>  Thank you again for your comments. Please respond to
>>  public-webont-comments@w3.org to let us know if our responses are
>>  satisfactoy.
>>
>>  Jeff
>>  > Ken
>>  >
>>
>>  [1]
>>  http://lists.w3.org/Archives/Public/public-webont-comments/2003Jun/0038.html
>>  [2]
>>  http://lists.w3.org/Archives/Public/www-webont-wg/2003Jul/0157.html

-- 
Professor James Hendler				  hendler@cs.umd.edu
Director, Semantic Web and Agent Technologies	  301-405-2696
Maryland Information and Network Dynamics Lab.	  301-405-6707 (Fax)
Univ of Maryland, College Park, MD 20742	  *** 240-277-3388 (Cell)
http://www.cs.umd.edu/users/hendler      *** NOTE CHANGED CELL NUMBER ***
Received on Friday, 18 July 2003 10:31:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:01 GMT