My review of ebXML Registry Profile for Web Ontology Language (OWL)

[ewallace@cme.nist.gov]

[[[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"

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.

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?

Comment 4:
page 18, line 548
Minor, editorial
 Typo - change "ExternallyLinks"  to "ExternalLink" to match class in 
 ebXML RIM inheritence view.

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 .


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.

 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.

Comment 7:
page 21, line 676
Minor, editorial
typo - change "a ClassificationNodes" to "a ClassificationNode"

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.

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.

Comment 10:
page 25, line 849
minor, typo

add missing quote by replacing
  "MyInsuranceService" succeeds MyHotelAvailabilityService" 
with
  "MyInsuranceService" succeeds "MyHotelAvailabilityService" 

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.

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.

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.

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".

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>

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.

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."

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".

***************************************************************************

-Evan

Evan K. Wallace
Manufacturing Systems Integration Division
NIST