RE: [Fwd: [deri-research] FW: OWL Full reasoning]

Hi Doug,
 
Thanks you for your response! I'll try to give the proper rebuttals below.
 
Kind regards,
Hans
-------------------------------------------------
 
-----Original Message-----
From: doug foxvog [mailto:doug.foxvog@deri.org] 
Sent: Friday, August 19, 2005 6:11 PM
To: semantic-web@w3.org; semantic-web-request@w3.org;
hans.teijgeler@quicknet.nl
Subject: [Fwd: [deri-research] FW: OWL Full reasoning]
 
> From: semantic-web-request@w3.org 
[mailto:semantic-web-request@w3.org] > On Behalf Of Hans Teijgeler
> Sent: Donnerstag, 18. August 2005 14:50
> To: semantic-web@w3.org
> Subject: OWL Full reasoning
 
> Hi,
 
[HT1] I have worked out an example of a reasoning problem that we have:
http://www.infowebml.ws/topics/RDF-OWL/85-reasoning/example.htm
[DF]There are some problems with the description in this example resulting
from inconsistency as to whether various classes are first-order
(classes of individuals) or second-order (classes of classes of
individual) or even third order (classes of classes of classes of
individual).  Consistency here is necessary before any attempt is
made for reasoning to solve the problem.
[HT2] I guess that if you study the entire hierarchy of the ISO 15926-2 data
model you would get the answers to that.
 
* [DP]The description of ValidConnectionPerANSI-B16.5 indicate that it is
   a second-order class, i.e. its instances are first-order classes, yet
   the question is posed whether an instance of DirectConnection, i.e.
   an individual, is an instance of a subClassOf of
   ValidConnectionPerANSI-B16.5 both in the text and in the figure.
[HT2] Is that a real problem in OWL? Not so in ISO 15926-2.
 
   + [DP]As a second-order class, this should probably be renamed
     ValidConnectionTypePerANSI-B16.5
[HT2] I wrote a note that all names are labels, and to paraphrase
Shakespeare:"What's in a label?".. In the meantime I extended the Topic on
our website with an RDF/XML listing (upon request of Danny). In that listing
I now defined all the entity data types that are in the applicable
subbranches of the hierarchy that starts with Thing (Note: the ISO 15926-2
Thing!).There you can see that the ID is ERDL__998342  (see
http://www.infowebml.ws/topics/RDF-OWL/85-reasoning/example.htm )
 
   + [DP] The class of all valid connections Per ANSI-B16.5 is useful,
having
     2"-150/300#RFFlangedConnection as a subclass. This corresponds to
     the existing name, ValidConnectionPerANSI-B16.5, but would not be an
     instance (much less a subclass) of ClassOfClasses.  It would be
     typed as a ClassOfIndividual.
[HT] The link between them is shown as 'type', not subClassOf.
 
* [DP]The figure depicts ValidConnectionPerANSI-B16.5 as a third-order
   class, i.e. its instances are second-order classes, because the
   link between it and ClassOfClasses is subClassOf instead of type.
   This should be a type link if the second-order class were meant.
[HT] Are we looking at the same problem?  The link IS 'type'.
 
*[DP]The three classes, ClassOfDirectConnection, ClassOfIndividual, and
   ClassOfInanimatePhysicalObject are first-order collections according
   to one set of depicted links, yet second-order collections according
   to another set of links.  Assuming these are intended to be second-
   order collections:
   + The link from 2"-300#RFFlange to ClassOfIndividual should be
     type, not subClassOf
[HT] Why? It is a subset of the set of all individuals in the world in the
past, present, and future (mind you: in ISO 15926-2 a possible_individual is
a 4D (space-time) object.)
   + The link from 2"-300#RFFlange to ClassOfIndividual should be
     type, not subClassOf
[HT] See above
   + The link from 2"-150/300#RFFlangedConnection to
     ClassOfDirectConnection should be type, not subClassOf
[HT] Not in our modelling paradigm: the ClassOfDirectConnection is the set
of all direct connection relationships between any two members of
ClassOfIndividual, and the set of all 2"-150/300#RF flanged direct
connections is a subset thereof (both in past, present, and future)
* The links from DirectConnection to PossibleIndividual should be
   classOfSide1 and classOfSide2 instead of side1 and side2
[HT] Why? Any instance of DirectConnection is related to two instances of
PhysicalObject. No Class in sight.
* The classOfSide1 and classOfSide2 links from ClassOfDirectConnection
   to ClassOfIndividual have different meaning than the classOfSide1 and
   classOfSide2 depicted from 2"-150/300#RFFlangedConnection.  Those from
   2"... indicate that any side1 link from an instance of 2"150/300... is
   an instance of 2"-300#RFFlange (and side2 links are instances of
   2"-150#RFFlange).
   The links from ClassOfDirectConnection should be classOfClassOfSide1/2
   indicating that instances of ClassOfDirectConnection should have
   classOfSide1/2 to instances of ClassOfIndividual.
[HT] Again: why? If translated in Swahili you wouldn't say that, but the
model is just the same. The names given to the Properties don't drive the
logic, not in our paradigm.
I guess that you say that because you see a type link, and we see a
subClassOf link (see two answers up)
 
* [DP]The first check in Reasoning for Phase 2 should check whether there is
   a subClassOf DirectConnection, not of ClassOfDirectConnection, with
   the described properties.  This class should be *typed* with the
   class, ClassOfDirectConnection.
[HT] No, see three answers up.
 
*  [DP]The second check should be whether the found OWL class is typed with
   the *instance*, not subClassOf, ClassOfClass labelled
   ValidConnectionTYPEPerANSI-B16.5 .  Alternatively, it could check
   whether the found class was a subClassOf a re-defined
   ValidConnectionPerANSI-B16.5, which would be a subClassOf
   DirectConnection (and be typed with ClassOfIndividual).
[HT] You lost me. The nice thing about an ISO standard is that you cannot
change it. You either comply or you don't, and what you want me to do is not
to comply. I have the impression that you may have to make the inverse of
the paradigm shift that I had to make when confronted with OWL for the first
time.
 
For the figure, the following type relations should hold:
 
Individuals                                                         of type
                DirectConnection-Yellow
DirectConnection
                FlangeOnPipeA265h                       PhysicalObject,
2"-150#RFFlange
                FlangeOnPumpP101                       PhysicalObject,
2"-300#RFFlange
 
First-Order Classes
                DirectConnection
ClassOfDirectConnection
                PossibleIndividual
ClassOfIndividual
                PhysicalObject
ClassOfIndividual
                2"-150/300#RFFlangedConnection
*ValidConnectionTypePerANSI-B16.5
                2"-300#RFFlange
ClassOfInanimatePhysicalObject
                2"-150#RFFlange
ClassOfInanimatePhysicalObject
                ValidConnectionPerANSI-B16.5*
ClassOfDirectConnection
 
Second-Order Classes
                ClassOfDirectConnection
ClassOfClasses
                ClassOfIndividual                            ClassOfClasses
                ClassOfInanimatePhysicalObject              ClassOfClasses
                ValidConnectionTypePerANSI-B16.5 ClassOfClasses
 
subClassOf relations should obtain between:
                PhysicalObject
PossibleIndividual
                DirectConnection
PossibleIndividual (?)
                2"-150#RFFlange
PhysicalObject
                2"-300#RFFlange
PhysicalObject
                2"-150/300#RFFlangedConnection
ValidConnectionPerANSI-B16.5
                ValidConnectionPerANSI-B16.5 DirectConnection
                ValidConnectionTypePerANSI-B16.5 ClassOfDirectConnection
                ClassOfInanimatePhysicalObject
ClassOfIndividual
                ClassOfDirectConnection
ClassOfIndividual
 
* Note that the figure does not have both ValidConnectionPerANSI-B16.5
   and ValidConnectionTypePerANSI-B16.5
 
> I have the following questions to the OWL community:
> 1.      Given the fact that this is clearly an implementation of OWL
>         Full, can any OWL reasoner handle this at present?
 
It has to be cleaned up if anything is to handle it.
 
I don't know of a OWL-Full reasoner.
 
OpenCyc can currently handle the cleaned-up version (if encoded in CycL
instead of in OWL).
 
> 2.      If not yet, may we realistically expect such a capability to
>         be available by the year 2010?
> 3.      And if not, why is there OWL Full?
 
> Regards,
> Hans
 
> _______________________
> Hans Teijgeler
> ISO 15926 specialist
>  <http://www.InfowebML.ws> www.InfowebML.ws
>  <mailto:hans.teijgeler@quicknet.nl> hans.teijgeler@quicknet.nl
> phone +31-72-509 2005
 
==========================================================
douglas foxvog    doug.foxvog@deri.org   +353 (91) 495 150
Digital Enterprise Research Institute (DERI)
National University of Ireland, Galway
Galway, Ireland
http://www.deri.ie
==========================================================
 

Received on Friday, 19 August 2005 19:34:14 UTC