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 Thursday, 17 April 2003 11:31:10 UTC