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

Antoine,

Thanks for your further comments. As before, I have tried
to either answer your questions or propose an editorial change 
that I think addresses them.

> Hello Mike,
> 
> > 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.

You've got the idea.  Note that the example would violate the range 
restrictions on the locatedIn and hasMaker properties, which are object 
properties.

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

Maybe the key analogy was a bad idea.  The idea of a key in the database 
sense is that it provides a unique index to a row in a table. If our mapping

is (B-><A>, C-><A>), then there is no unique id for <A>. The reason I 
changed the text to 'pairs' was to convert the previously erroneous text 
to a description supporting a mapping like (B-><A,B>, C-><A,C>).

I will just delete the paragraph.  The preceding paragraphs include

 P(y,x) and P(z,x) implies y = z 

and

 The reason is that the inverse of a functional property
 must be inverse functional. 

with seems more than sufficient and less confusing.

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

Unless it is deemed truly awful, the WG is unlikely to rename properties at
this point.

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

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, 30 April 2003 18:32:31 UTC