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

Re: current version of Feature Synopsis document

From: <herman.ter.horst@philips.com>
Date: Tue, 11 Jun 2002 15:35:07 +0200
To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
Cc: www-webont-wg@w3.org
Message-ID: <OF30A7A7D4.6E5632C8-ONC1256BD5.004AA08F@diamond.philips.com>
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). 
The special thing about this document is that it describes OWL in a way 
that 
abstracts from concrete syntax: 
this does not need to influence the basic terminology.
I would say that this document uses the subset of the terminology that is
needed for talking about the underlying language concepts in a way that 
does not deal with concrete syntax.  Keeping the term individual implies 
two 
terms for the same thing: hence my suggestion to simplify.

> > There is now a reference to model-theoretic semantics.
> > This is a meta-remark. I suggest combining all meta remarks
> > in Section 1 (and/or an appendix), so that Sections 2, 3, 4 are 100% 
> > devoted to what the document title says: giving a feature synopsis of 
> > full OWL. 
> 
> I feel that this would unduely complicate the document.  Why not leave 
the
> (small) description of the meaning of the features in-line?

I fully agree to leave these descriptions of meaning in-line.  In this 
way, 
the document becomes an overview of language features and their meaning.
What I meant to say is that only the reference to model-theoretic 
semantics 
can be moved (to Section 1) because it is not such a description of a 
language 
feature, and because at this point it interrupts this feature synopsis.

> At this point in the text there still is a gap in the 
> > description of the language features and their meaning, which could be 

> > closed with sentences like:
> > -Classes denote subsets of the set of all individuals.
> > -Properties denote sets of pairs of individuals and/or data values.
> 
> These are in the last paragraph of section 2.

You did not include the second sentence I suggested above.
The  sentence that you do have, "Properties relate individuals to other 
information", is more vague.  I suggest to make this 'act of relating' 
more 
specific, by saying that a property specifies certain pairs, nothing more 
and nothing less.

> > Second remark: Use the term frame only in historical/meta remarks
> > (to be moved out of the feature presentation flow). 
> > Each simplification of terminology reduces the threshold 
> > between OWL and its potential users.
> 
> Why should there not be an allusion to frames?  This way of organizing 
the
> axioms was chosen partly for its similarity to frames, so I see only
> utility in mentioning the relationship. 

My point is that this is informative only for people who know about 
frames, 
while the intended audience is much larger.
The word frame occurs three times: in Sections 1, 3, and 3.2.
The latter two occurrences can be omitted.

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.

> > 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.


(By the way, Peter: in spite of several changes that you made to the 
document, 
the date of the document is the same as that of the previous version: 6 
June.)

Herman ter Horst
Received on Tuesday, 11 June 2002 09:38:12 GMT

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