W3C home > Mailing lists > Public > www-webont-wg@w3.org > June 2002

Re: current version of Feature Synopsis document

From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
Date: Wed, 12 Jun 2002 03:54:57 -0400
To: herman.ter.horst@philips.com
Cc: www-webont-wg@w3.org
Message-Id: <20020612035457Y.pfps@research.bell-labs.com>

From: herman.ter.horst@philips.com
Subject: Re: current version of Feature Synopsis document
Date: Tue, 11 Jun 2002 15:35:07 +0200

> Below I only include the points where I want to make a further remark.
> > > The term individual-valued property is an improvement.
> > > However, the ambiguous phrase "Individual IDs" remains.
> > > Replacement of the term individual by resource would
> > > simplify terminology.
> > 
> > I resist this change.  The term ``resource'' is, I feel, not appropriate 
> at
> > the level of this document. 
> It seems that the context of the (Semantic) Web fixes the term for 
> individual 
> to be resource (as it fixes the term for binary relation to be property). 

RDF has a particular notion of the term ``resource''.  This may not be the
same as what OWL needs for ``individual''.  If it is not, then OWL needs a
different name, and no change need be made to the document.  If it is, then
it is easy to change the OWL documents.  However, if the documents use
``resource'' before the situation is determined, then changing would be
very hard.


> By the way, looking again at Section 3, I noticed that the second 
> paragraph 
> needs change: it is still phrased in terms of the earlier organization of 
> the class axioms (with supers and restrictions).
> > > The notion of restriction was considered difficult in DAML+OIL.
> > > I suggest to replace the first, brief, explanatory sentence by the 
> more 
> > > explicit sentence: "Restrictions enable the definition of classes in 
> > > terms of constraints on properties."
> > 
> > I view this sentence as more misleading than what is currently there.  I
> > have, however, modified the current text.
> Do we read these sentences differently?
> Your sentence says: "Restrictions provide constraints on properties, which 
> can
> be used in classes."
> However, a property (that is, the set of pairs that it denotes) can only 
> be 
> constrained (that is, restricted in possible extents) by property axioms. 
> Restrictions cannot constrain the set of pairs denoted by a property.
> Restrictions can constrain the set of individuals that are instances of a 
> certain class.
> I find that this is better expressed by my suggested sentence.

OK.  I've changed the wording here.

> > > The first line of the <propertyValue> production implies that a 
> > > <individualFact> always stands for an individual.
> > 
> > Yes, an individualFact is an Individual, i.e., an RDF description 
> element
> > with a slighly different syntax.
> > 
> > > But the production for <individualFact> says that a <individualFact> 
> > > stands for one or more assertions about an individual.
> > 
> > Yes, an individualFact can include one or more propertyValues, each of
> > which provides information about the individual.
> > 
> > > What is meant here? 
> > 
> > Very close to what is meant in RDF.
> Clear. I suggest to include an explanatory sentence saying that an
> individualFact is taken to stand for an individual, as in RDF.
> In this way, the part of the document dealing with individualFacts
> can be read without such knowledge about RDF.
> > > It is desirable to add explanation about how facts about anonymous 
> > > individuals work.
> > 
> > You mean besides referring to RDF?  I'm not particularly willing to 
> include
> > enough to make a significant difference in comprehensibility.
> I would hope that the essence can be explained in just a few sentences
> (on the abstract level of this document).
> I am in favor of making this document essentially self-contained.
> If no explanation is given, then, in my view, this document needs an 
> explicit 
> reference to another document with such an explanation.


Received on Wednesday, 12 June 2002 03:55:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:56:44 UTC