RE: RE : Remarks on OWL Guide and question about AS&S

Antoine,

See my suggested rewording at the end of the extract.

> > > > > -> section 3.4.2
> > > > > 
> > > > > [
> > > > > owl:maxCardinality can be used to specify an upper bound. 
> > > > > owl:minCardinality can be used to specify a
> > lower bound. In
> > > > > combination, the two can be used to specify a range. ]
> > > > > 
> > > > > Perhaps a typo : "cardinality" (or "owl:cardinality") instead of 
> > > > > "range" ?
> > > > 
> > > > I'm using range in the [n...m] sense.  Will change to "numeric
> > > > range".
> > > 
> > > For my humble brains it stills sound confusing. A numerical
> > function
> > > may have something called a "numeric range", but in my opinion it
> > > would still be the "owl:range" meaning (even though restrected to a 
> > > set of numbers). How about using "cardinality range" ?
> > 
> > The trouble with 'cardinality range' is that it is a new
> > concept, within 
> > OWL, that we would need to define somewhere.  I was trying to 
> > reference 
> > well-understood concepts from outside OWL.  I would propose 
> > replacing 'range' with 'numeric interval' (thanks to Jeremy 
> > Carol for this suggestion).
> 
> A numeric interval is indeed what is to be used to described an
> [n...m] interval, but then it does not make sense any more in the
> sentence
> 
>  [owl:maxCardinality can be used to specify an upper
> 	bound. owl:minCardinality can be used to specify a 
> 	lower bound. In combination, the two can be used to specify a
*numeric interval*. ]
> 
> since we lose the fact that this interval bounds the property
> cardinality. I would sugger to add "bounding the property cardinality"
> (or a more suitable verb : my english vocabulary is quite loose) at
> the end of your rewording.

  owl:maxCardinality can be used to specify an upper
  bound. owl:minCardinality can be used to specify a 
  lower bound. In combination, the two can be used to limit the 
  property's cardinality to a numeric interval.

Please reply to the mailing list as to whether the above changes 
adequately address your comments.

- Mike

Michael K. Smith, Ph.D., P.E.
EDS - Austin Innovation Centre
98 San Jacinto, #500
Austin, TX  78701

phone: +01-512-404-6683
email: michael.smith@eds.com

-----Original Message-----
From: Antoine Isaac [mailto:aisaac@ina.fr] 
Sent: Thursday, April 17, 2003 10:36 AM
To: 'Smith, Michael K'; public-webont-comments@w3.org
Subject: RE : Remarks on OWL Guide and question about AS&S


Hello Mike,

> -----Message d'origine-----
> De : public-webont-comments-request@w3.org
> [mailto:public-webont-comments-request@w3.org] De la part de 
> Smith, Michael K
> Envoyé : jeudi 17 avril 2003 14:57
> À : Antoine Isaac; public-webont-comments@w3.org
> Objet : RE: Remarks on OWL Guide and question about AS&S
> 
> 
> 
> Antoine,
> 
> Thanks again for your comments. In this message I have tried to either 
> answer your questions or propose an editorial change that I think 
> addresses them.

And you've succeeded by large. Thanks. Nevertheless, as explanations always
raise more questions, I have some further comments. In this mail I only left
the pieces of your previous mail that were relevant to these comments.


> > -> sections 3.2.2 and 3.2.3
> > 
> > In section, 3.2.2, yearValue is specified has having a 
> > xsd:positiveInteger range. In the next section, the individual 
> > Year1998 id defined by :
> > 
> > [
> > <VintageYear rdf:ID="Year1998">
> >   <yearValue rdf:datatype="&xsd;positiveInteger">1998</yearValue>
> > </VintageYear>
> > ]
> > 
> > Is the specification of rdf:datatype="&xsd;positiveInteger"
> mandatory?
> 
> Yes, if we want 1998 to be considered a positive integer.
> 
> > Is is linked to RDF syntax considerations or just an examplification 
> > of what could optionnally be written? Is
> 
> > <VintageYear rdf:ID="Year1998">
> >   <yearValue>1998</yearValue>
> > </VintageYear>
> > 
> > correct?
> 
> No.  Not if you want '1998' to be an integer.  1998 as above
> is a 'plain 
> literal' as opposed to a 'typed literal'.  See 
> http://www.w3.org/TR/2003/WD-rdf-concepts-20030123/#dfn-plain-literal
> We expect tools to help with these verbose constructs.

OK. It is just like if we tried to assert

<CabernetSauvignon rdf:ID="SantaCruzMountainVineyardCabernetSauvignon" >
  <locatedIn>SantaCruzMountainsRegion</locatedIn>  
  <hasMaker>SantaCruzMountainVineyard</hasMaker>   
</CabernetSauvignon>

without "rdf:ressource=" pointing towards already-defined ressources, or
without "real" inserted OWL instance definitions. Isn't it ? With such an
assertion, a system couldn't infer that those literals are the names of a
Region and a Wineyard.

> 
> > -> section 3.3, InverseFunctionalProperty subsection
> > 
> > [
> > <owl:ObjectProperty rdf:ID="producesWine">
> >   <rdf:type rdf:resource="&owl;InverseFunctionalProperty" />
> >   <owl:inverseOf rdf:resource="#hasMaker" />
> > </owl:ObjectProperty>                                     ¬
> > 
> > Think of the elements of the range in an inverse functional property 
> > as defining a unique key in the database sense.
> owl:InverseFunctional
> > implies that the elements of the range provide a unique
> identifier for
> > each element of the domain. ]
> > 
> > In this case, a Wine can be used to identify a Winery, but
> it is not a
> > *unique* key, since several wines can be produced by a single winery 
> > (which seems to be allowed by the last sentence of the previous 
> > section).
> 
> You are right.  This is phrased incorrectly.  The idea was that a
> 'unique key' applies to a tuple and the text should not have stated 
> that it is a unique identifier for the domain elements.
> 
> Suggested rewording:
> 
> [
> Think of the elements of the range in an inverse functional property
> as defining a unique key in the database sense. owl:InverseFunctional 
> implies that the elements of the range provide a unique 
> identifier for 
> each pair contained in the property. ]

I finally managed to understand (and to agree with) your rewording, but it
still sounds difficult. Perhaps it would be better to cancel it or to
exemplify it with your wines and wineries. Even if

[If ChateauMargotWinery producesWine ChateauMargotWhite and
ChateauMargotRed, then {ChateauMargotRed} gives a key for
ChateauMargotWinery, as well as {ChateauMargotWhite}, as well as
{ChateauMargotWhite, ChateauMargotRed}]

is still confusing, at least it gives something more concrete.

> 
> > I have understood that there has been lots of arguing about the 
> > meaning of this property (I know this issue has been
> largely discussed
> > in the rdf-logic list, but I do not find the thread....). Indeed I
> > believed I had got it, until I saw the two last paragraph of the 
> > subsection. In my understanding of the definitions, an 
> > InverseFunctionalProperty gives a key provided it has an 
> exactly-one
> > cardinality restriction on its range.
> 
> Yes.  Your understanding was correct.

Recalling some math courses, I wondered whether "injective relation" could
be used, but a quick search on the net revealed that people used this
expression to refer to injective *functions*, thus not fitting our
one-to-many inverse-functional property. Unless people turn the definition
of "injective" into something like "if p(a) and p(b) are not disjoint (a and
b being instances, p(a) and p(b) sets of instances, the sets of the values
of property p for a and b) then a=b", "inverse functionnal" will probably
remain the best choice. Or something like "disjointValuedProperty", if it
has not been rejected by the WebOnt group yet.

> 
> > -> section 3.4.2
> > 
> > [
> > owl:maxCardinality can be used to specify an upper
> > bound. owl:minCardinality can be used to specify a lower bound. In 
> > combination, the two can be used to specify a range. ]
> > 
> > Perhaps a typo : "cardinality" (or "owl:cardinality") instead of 
> > "range" ?
> 
> I'm using range in the [n...m] sense.  Will change to "numeric range".

For my humble brains it stills sound confusing. A numerical function may
have something called a "numeric range", but in my opinion it would still be
the "owl:range" meaning (even though restrected to a set of numbers). How
about using "cardinality range" ?

Thanks for your concern,

Antoine

Received on Wednesday, 7 May 2003 11:27:03 UTC