- From: Antoine Isaac <aisaac@ina.fr>
- Date: Thu, 17 Apr 2003 17:36:06 +0200
- To: "'Smith, Michael K'" <michael.smith@eds.com>, <public-webont-comments@w3.org>
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