Guide Comments: Proposed response to Antoine Isaac

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.

> 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
erroneus text to describe a mapping lie (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.  

> > > 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.  And, while
'numeric range' is clearly related to "owl:range", I think it can be
understood independently.  I would prefer to keep it 'numeric', with
the expectation that this is something most readers will relate to
their prior (non-OWL) experience.

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

Received on Sunday, 27 April 2003 14:10:47 UTC