Re: [regrep-semantic] My review of ebXML Registry Profile forWeb Ontology Language (OWL)

[cmattocks@metlife.com]

I plan to have my comments to you by end of this week. Hopefully this will allows the SC to publish the spec to the broader group by end of March.


Carl Mattocks
Consultant : ITIL Application Knowledge Management
MetLife 732 893 4170

'Always look on the bright side of life' Monty Python
"Asuman Dogac" <asuman@srdc.metu.edu.tr>

"Asuman Dogac" <asuman@srdc.metu.edu.tr> 03/06/2006 11:37 AM

To: ewallace@cme.nist.gov cc: regrep-semantic@lists.oasis-open.org, "yildiray" <yildiray@srdc.metu.edu.tr>, gokce@srdc.metu.edu.tr Subject: Re: [regrep-semantic] My review of ebXML Registry Profile for Web Ontology 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

The information contained in this message may be CONFIDENTIAL and is for the intended addressee only. Any unauthorized use, dissemination of the information, or copying of this message is prohibited. If you are not the intended addressee, please notify the sender immediately and delete this message.