[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep-semantic] My review of ebXML Registry Profile for WebOntology Language (OWL)
Dear Evan, Thank you very much for your comments; with this contribution I believe you would not mind becoming a contributor to the profile:-) I have inserted your name. Enclosed I will explain how we handled them. ewallace@cme.nist.gov wrote: > [[[note that I will be out Feb 20, so I won't see any responses to this > before Tuesday]]] > > My comments on > "ebXML Registry Profile for Web Ontology Language (OWL)" > Version 1.0 draft 2 > > Note that my review of the document focused on the aspects which > directly related to OWL, such as: descriptions of OWL language > constructs, OWL examples, and some aspects of the descriptions of how > OWL semantics are supportable in an ebXML RegRep. I am not an expert > in ebRIM nor in db stored procedures, so I tended to skim those > sections. > > I have numbered the comments in order to make them easy to reference > in future discussions. In general, I believe this profile is quite > good. Do not interpret the number of comments as an indicator that > this is not the case. Most comments can be easily fixed, and I > included suggestions for that. > > > Comment 1: > Page 10, line 261 > Minor, editorial > Typo - change "it worths" to "it is worth" > > Corrected. > Comment 2: > page 12, lines 323-324 > Significant, content > > Why only OWL Lite support? OWL Lite has not emerged as a > particularly popular OWL dialect. I suggest that you add text in this > section explaining why you chose to support only Lite and whether the > profile could be easily upgraded to DL and/or Full in the future. > OWL DL support is being added; we will release the new version as soon as it is completed. We have avoided OWL Full for the following reason: "It is unlikely that any reasoning software will be able to support complete reasoning for every feature of OWL Full." as stated in OWL Overview: http://www.w3.org/TR/2004/REC-owl-features-20040210/#s1.3 > Comment 3: > page 17, Listing 7 > Question > > As I noted in the intro to these comments, I am not an ebRIM expert. > While reading section 3 the Registry overview section, I ran across > something in the Object Classification example that I didn't expect > from my reading of the RIM model in figure 1. I expected an instance > of a Classification to include/identify two things: a > ClassificationScheme and a ClassificationNode. The example shows two > things: a classificationNode (which seems to have the > classificationScheme name embedded) and classifiedObject. Is > classifiedObject the rolename (elided in model) for the > RegistryObject side of the "classifications" association shown > between a Classification object and a RegistryObject in the RIM > figure? Where is the classificationScheme element in this example? > > That section on ebXML was readily available for us to use:-) from an earlier document that Farrukh has co-authored, namely, "ebXML Profile for Web Services". RIM, through Classification object indeed associates a ClassificationNode to a RegistryObject. The ClassificationScheme that the ClassificationNode belongs to (if there exists any; it can be a node by itself) can be obtained from the registry. > Comment 4: > page 18, line 548 > Minor, editorial > Typo - change "ExternallyLinks" to "ExternalLink" to match class in > ebXML RIM inheritence view. > "ExternallyLinks" is the name of the Association Type so I believe it is correctly used in the text. > Comment 5: > page 20, Example owl:Class > Major, editorial > > In RDFS, subClassOf asserts a subsumption relationship between > subject and object. The example (in triple form) > > City rdf:type owl:Class . > City rdfs:subClassOf Country . > > asserts that every individual of class City is also an individual of > class Country. This is not the case for what most english speakers > understand of cities and countries. Suggest that if you keep the > subclassof part of this example that you change one or the other > classes in this triple. Some alternative examples are > > City rdfs:subClassOf GeoPoliticalEntity . > > or > > CapitolCity rdfs:subClassOf City . > > > Corrected. > Comment 6: > page 20, Example Corresponding ebRIM construct ClassificationNode > Major, content > > In this example you use the parent link in the classification model > to define a superclass for the class the node represents. Later > though (in 4.1.4) you point out that this method doesn't support multiple > inheritence which is a basic feature of RDFS and OWL. Do you mean to > support both mechanisms in this profile? I think that unwise. > Suggest that you simplify this example to just <owl:Class rdf:ID="City"> > eliminating the subclassing issue and the use of parent in the > corresponding ClassificationNode. > > We are not using "parent" attribute anymore. > Question: Farrukh: Can we point out areas for enhancement of the > ebRIM in a profile document? An extension/revision of the > Classification model in the RIM to support ontologies/vocabularies by > allowing more than one parent for a Node would be a small change, but > big win IMHO. > > Multiple inheritance is Farrukh's domain. > Comment 7: > page 21, line 676 > Minor, editorial > typo - change "a ClassificationNodes" to "a ClassificationNode" > > Corrected. > Comment 8: > page 22, section 4.1.5 > Significant, Editorial > > I am uncomfortable with the object model-style description of > classes, properties, and instances used in this section. It may give > people the wrong impression about classes and individuals in RDFS and > OWL. In RDFS/OWL, MyTravelService doesn't "inherit" the > paymentMethod property. Rather: > > <owl:ObjectProperty rdf:ID="paymentMethod"> > <rdfs:domain rdf:resource="#TravelWebService"/> > <rdfs:range rdf:resource="#PossiblePaymentMethods"/> > </owl:ObjectProperty> > > licenses the following inference: > > If I have the rdf triple > MyTravelWebService TravelWebService Cash . > > then an RDF tool could infer > MyTravelWebService rdf:type TravelWebService . > Cash rdf:type PossiblePaymentMethods . > > and nothing more. The above rdf/xml description for paymentMethod > does not require that individuals of type TravelWebService have a > value (aka filler) for the paymentMethod property, nor does it > prevent such individuals from having values for properties not > mentioned. It is also the case that MyTravelWebService could also > be a member of other classes in addition to TravelWebService and its > superclasses. So, unlike in many object languages, individuals in > RDF and OWL are not defined with a single, most specific, type. > > I am not sure what the purpose of this text (lines 709 - 729) serves > in this section. Perhaps it is to explain the nature of facts > (often referred to as RDF data) in an RDF/OWL KB, and how -in the > ebReg/Rep world- these facts belong in a Repository rather than a > Registry. This text should either be removed or rewritten. I would > be willing to draft some alternate text if a rewrite is the > preferred fix. > I will highly appreciate if you provide the text. > Comment 9: > page 24, Example owl:DatatypeProperty, lines 825,826 > Significant, typo? > > This example currently says that the hasPrice DatatypeProperty is a > subPropertyOf Profile.owl. Presumably you meant it to be a > subproperty of some datatype property defined in Profile.owl. I > suggest you just remove the two lines in question from the example. > Reusing elements of OWL-s ontologies, could push your examples into > OWL Full. > Corrected. > Comment 10: > page 25, line 849 > minor, typo > > add missing quote by replacing > "MyInsuranceService" succeeds MyHotelAvailabilityService" > with > "MyInsuranceService" succeeds "MyHotelAvailabilityService" > > Corrected. > Comment 11: > page 25, section 4.3.4 > discussion of using inverseOf knowledge in lines 876 - 880 > question, OWL Profile usage issue > > The example of how to make use of knowledge about inverse properties > described here raises a larger question. The example implies that > the knowledge/fact base in a reg/rep is only partially populated > prior to when queries are performed. That would be a reasonable > assumption in a semantic web environment, but might it be different > in a reg/rep environment? An alternative way that one might use the > additional semantics that this profile supports would be to cause > inferred information to be produced and stored along with new data as > that new data was inserted into the reg/rep. Thus the extra work of > inferring is only done at insertion/update time, instead of at query > time. > We have proposed this as an alternate strategy. > Comment 12: > page 26, section 4.3.7, lines 917-918 > medium, editorial > > The description of inverseFunctional properties, excerpted here from > the OWL Overview document, is one of the few cases where that document > doesn't shed much light on the subject. While what it says is true, > it is convoluted and essentially repeats what the reader could have > guessed from the name of the language element. > > InverseFunctional properties (IFPs) are like keys. An individual > filling the range role in an inverseFunctional property instance > identifies the individual in the domain role of that same property > instance. In other words, if a semantic web tool encounters two > individuals with the same value for an inverseFunctional property, it > can be inferred that they are actually the same individual (so data > about these could be merged - or "smushed" in Sem Web parlance). The > FOAF vocabulary exploits this to identify people via their email > addresses by defining foaf:mbox as an inverseFunctional property. > > Clearly, it is not so easy to describe this concisely and simply. I > see why the OWL Overview authors punted. I am not ready to give up yet, > however. > The explanation you have provided seemed fine to us. If you wish to provide another, that is also fine. > Comment 13: > page 26, Example owl:InverseFunctionlProperty > content incorrect > > There are two problems with the example for > InverseFunctionalProperty. First "departsFrom" should have a domain > of type Flight. But once it does, it is clear that it is not an > inverseFunctionalProperty (the second problem) as many flights depart > from the same airport (thus the Airport does not uniquely identify the > Flight). > > foaf:mbox is one example of an IFP. isBiologicalMotherOf is another > example. hasAssembled could also be an example with a domain of > AssemblyPlant and a range of Automobile. One can find exceptions to > all these examples in the real world. But this just supports my view > that IFP's are somewhat unnatural, and that compound IFPs would be > more useful. In any case, you need to replace your example. Either > use one of mine, or think up a different one. > > Corrected. > Comment 14: > page 26, section 4.4, line 934 > editorial, content > > Instead of saying: "The aim is to make ontologies more extendable and > hence more reusable," I would say "This makes property definitions > more reusable by factoring out class specific characteristics of > the property into the class description". > > Inserted. > Comment 15: > page 27, section 4.4, Example owl:Restriction on ObjectProperty > "paymentMethod" > editorial, format/typo > > Indenting seems to have been munged in the rdf/xml of this example. > Line 947 should be outdented to match text in line 952 and lines 949 > and 950 should be indented further. As you have done elsewhere and as > shown below: > > <owl:Class rdf:ID="AirReservationServices"> > <rdfs:subClassOf> > <owlRestriction> > <owl:onProperty rdf:resource="#paymentMethod"/> > <owl:allValuesFrom rdf:resource="#CreditCard"/> > </owl:Restriction> > </rdfs:subClassOf> > </owl:Class> > > Corrected. > Comment 16: > page 27, section 4.4, lines 955-957 and lines 964-966 > multiple serious issues > > This text claims: > > Obviously,this serves only the purpose of reusing the > "paymentMethod" property Otherwise,a new property "paymentMethodCC" > can be defined between "AirReservationServices"and the "CreditCard" > classes as shown in the following: > > <owl:ObjectProperty rdf:ID="paymentMethodCC"> > <rdfs:domain rdf:resource="#AirReservationServices"/> > <rdfs:range rdf:resource="#CreditCard"/> > </owl:ObjectProperty > > > We believe that defining a generic Association Type and and keeping > track of its various restrictions in relational tables will bring > considerable overhead to the system Since an Association Type can > always be defined in ebXML between any RergistryObjects,we also > think that the expressive power is already there. > > With respect to OWL there are a number of serious issues with this > section. > > 1) It only addresses allValuesFrom restrictions (universal role > quantification). OWL Lite also supports someValuesFrom restrictions > (existential role quantification). Note that minCardinality > restrictions of 1 are not quite equivalent to someValuesFrom, > minCardinalityQ restrictions of 1 would be, but OWL doesn't have > qualified cardinality restrictions. > > 2) But even with respect to allValuesFrom, > > <owl:Class rdf:ID="AirReservationServices"/> > > <owl:ObjectProperty rdf:ID="paymentMethodCC"> > <rdfs:domain rdf:resource="#AirReservationServices"/> > <rdfs:range rdf:resource="#CreditCard"/> > </owl:ObjectProperty > > > Does not have quite the same meaning as: > > <owl:Class rdf:ID="AirReservationServices"> > <rdfs:subClassOf> > <owlRestriction> > <owl:onProperty rdf:resource="#paymentMethod"/> > <owl:allValuesFrom rdf:resource="#CreditCard"/> > </owl:Restriction> > </rdfs:subClassOf> > </owl:Class> > > The restriction says that all fillers for the property paymentMethod > for all individuals of AirReservationServices must be of type > CreditCard. This is typically in the context of many other uses of > the paymentMethod property in other class definitions and in other > property definitions (such as subproperty/superproperty relations).. > > In contrast, the class and property defs above merely define a class > and a property where: if there are any instances of the property one > can infer the type of the individuals in each role. Yes, this also > means that all fillers for the property paymentMethodCC for all > individuals (including those of type AirReservationServices) must be > of type CreditCard. However, since paymentMethodCC is only defined > with respect to these two classes it has little meaning. It is the > inclusion of paymentMethod in many statements about other classes > and properties that gives it meaning. Meaning that can potentially > be used to deduce things about AirReservationServices and how that > class relates (subclassOf, disjointWith, equivalentTo, etc.) to > other classes which have some relation to paymentTypes (on its > inverse). The whole point to OWL is to give meaning to the terms it > describes. Thus "reusing the "paymentMethod" property" is critical > to an OWL ontology, and not merely something nice to have. If the > "expressive power is already there", you have not shown it. > > Note that even if you add <rdfs:subPropertyOf > rdf:resource=#paymentMethod/> to the definition of paymentMethodCC, > it still won't mean the same as the restriction, since there is no > way to say that the *all* the instances of paymentMethod for > AirReservationServices must be instances of paymentMethodCC. > > 3) Even if this were an acceptable way to handle allValuesFrom > restrictions (and I am not yet convinced of that) you need to define > mapping rules to support it. These mapping rules would describe a > scheme for naming all the global properties that you will be > creating which didn't exist in the corresponding OWL. And if you do > this, you should define each of these new properties as > subproperties of the property being restricted in the corresponding > OWL. Doing that is essentially downgrading the OWL to RDFS, but > that's better than losing the property relationships altogether. > We described a more elaborate way of handling this issue. > Comment 17: > page 27, section 4.5.1, lines 970 and 971 > minor, content > > I realize that this text comes from OWL Overview, but it is slightly > misleading. Cardinality restrictions can be applied to > DatatypeProperties as well as ObjectProperties. A more general > description covering this might say "...then any instance of the > class will have at least one value for the restricted property" in > place of "then any instance of the class will be related to at least > one individual by that property." > Inserted. > Comment 18: > page 29, section 4.6, line 1075 > minor, editorial > > More then two classes may be intersected. Change "both of the > classes" to "all intersecting classes". > Corrected. Evan, once again, thank you very much for your helpful comments and best regards, Asuman, Yildiray, Gokce Banu > *************************************************************************** > > -Evan > > Evan K. Wallace > Manufacturing Systems Integration Division > NIST > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- ____________________________________________________________________________ Professor Asuman Dogac email: asuman@srdc.metu.edu.tr WWW: http://www.srdc.metu.edu.tr/~asuman/ Director Phone: +90 (312) 210 5598, or Software R&D Center +90 (312) 210 2076 Department of Computer Eng. Fax: +90 (312) 210 1004 Middle East Technical University +90 (312) 210 1259 06531 Ankara Turkey skype: adogac
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]