Scott, Thanks for the reply.
The XML Schema I posed is highly representative of many XML Schemas I have seen, whereby those definitions that employ choice compositors require XML instance documents to exercise one option over another. Clearly, an XML Schema is purely structural in nature, but one can imply semantics from it. The TBC XML Schema import engine does so. For example, a "Person" class is derived from the "Person" XML Schema definition, since the definition describes a complex type. Additionally, it derives the object properties "hasMale" & "hasFemale", since the "Male" & "Female" XML Schema elements are both nested within the "Person" element and are themselves complex types. However, the TBC import engine appears to disregard XML Schema compositors (<xs:sequence>, <xs:choice> & <xs:all>), although the solution is not straightforward. For example, suppose the XML Schema "Person" definition had a sequence compositor and not a choice compositor. An XML instance document's Person element would require "Male" and "Female" elements. An OWL Person class could express this with a union operation on "hasMale" & "hasFemale" property restrictions. Naturally, the semantics cannot express the notion of order, but that is acceptable. In fact, a union operation would apply to both <xs:sequence> (ordered) and <xs:all> (unordered) compositors. It is more difficult to define an axiom that semantically expresses a <xs:choice> compositor. The <owl:intersectionOf> construct alone does not alone capture this. For example, having an intersection operation wrapped around "hasMale" & "hasFemale" value constraints would likely result in the empty set at the individual level. It is likely, though not guaranteed, that "Male" & "Female" class extensions are mutually exclusive. So, an intersection operation would yield zero members. If we were to assert that the "Male" & "Female" classes are disjoint, thereby providing a guarantee that the class extensions are indeed mutually exclusive, TBC may flag the ontology as inconsistent, since we may define an axiom that tries to execute an set operation that is invalid over disjoint classes. I suppose we would need to bring in <owl:complementOf> to help us out. Summing up, how does one express the implied semantics of an XML Schema choice compositor for this particular example in OWL? Thank you all in advance for your feedback. Regards, Anthony On Nov 3, 7:06 pm, Scott Henninger <[EMAIL PROTECTED]> wrote: > I have some questions on whether you want your choice to be among > schema definitions or instances. If you define this as a choice > amongst instances, then the instances would be in an instances file an > you define a schema such as the following: > > <?xml version="1.0" encoding="UTF-8"?> > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; > elementFormDefault="qualified" attributeFormDefault="unqualified"> > <xs:element name="Person"> > <xs:complexType> > <xs:choice> > <xs:element name="hasGender" type="GenderType" /> > </xs:choice> > </xs:complexType> > </xs:element> > > <xs:complexType name="GenderType" /> > </xs:schema> > > This will be interpreted by Composer by creating a class Person which > is restricted to members that have an instance of hasGender whose > value is from the class Gender. You would then create 'Male' and > 'Female' as instances of Gender. Note when this is converted to OWL > that the Person subClassOf restriction states that there can only be 1 > instance (cardinality) and that the instance must be from the class > Gender (someValuesFrom). This gives a clean separation between the > schema definition and the data that defines the choices. > > -- Scott > > On Nov 3, 2:42 pm, SemanticsQuest <[EMAIL PROTECTED]> wrote: > > > > > Hello, all. > > > I am running TBC ver-2.6.2 on top of Eclipse ver-3.4. > > > Consider the following XML Schema. > > > <?xml version="1.0" encoding="UTF-8"?> > > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; > > elementFormDefault="qualified" attributeFormDefault="unqualified"> > > <xs:element name="Person"> > > <xs:complexType> > > <xs:choice> > > <xs:element name="Male" type="MaleType" /> > > <xs:element name="Female" type="FemaleType" /> > > </xs:choice> > > </xs:complexType> > > </xs:element> > > > <xs:complexType name="MaleType" /> > > <xs:complexType name="FemaleType" /> > > </xs:schema> > > > The TBC XML Schema import engine produces the following OWL ontology: > > > <?xml version="1.0"?> > > <rdf:RDF > > xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; > > xmlns:xsd="http://www.w3.org/2001/XMLSchema#"; > > xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"; > > xmlns:owl="http://www.w3.org/2002/07/owl#"; > > xmlns="http://www.owl-ontologies.com#"; > > xml:base="http://www.owl-ontologies.com";> > > <owl:Ontology rdf:about=""> > > <owl:versionInfo rdf:datatype="http://www.w3.org/2001/ > > XMLSchema#string" > > >Created with TopBraid Composer from the XML > > Schemahttp://www.owl-ontologies.com</owl:versionInfo> > > </owl:Ontology> > > <owl:Class rdf:ID="Female"/> > > <owl:Class rdf:ID="Male"/> > > <owl:Class rdf:about="http://www.w3.org/2001/XMLSchema#Any"/> > > <owl:Class rdf:ID="Person"> > > <rdfs:subClassOf> > > <owl:Restriction> > > <owl:maxCardinality rdf:datatype="http://www.w3.org/2001/ > > XMLSchema#int" > > >1</owl:maxCardinality> > > <owl:onProperty> > > <owl:ObjectProperty rdf:ID="hasFemale"/> > > </owl:onProperty> > > </owl:Restriction> > > </rdfs:subClassOf> > > <rdfs:subClassOf> > > <owl:Restriction> > > <owl:allValuesFrom rdf:resource="#Female"/> > > <owl:onProperty rdf:resource="#hasFemale"/> > > </owl:Restriction> > > </rdfs:subClassOf> > > <rdfs:subClassOf> > > <owl:Restriction> > > <owl:maxCardinality rdf:datatype="http://www.w3.org/2001/ > > XMLSchema#int" > > >1</owl:maxCardinality> > > <owl:onProperty> > > <owl:ObjectProperty rdf:ID="hasMale"/> > > </owl:onProperty> > > </owl:Restriction> > > </rdfs:subClassOf> > > <rdfs:subClassOf> > > <owl:Restriction> > > <owl:allValuesFrom rdf:resource="#Male"/> > > <owl:onProperty rdf:resource="#hasMale"/> > > </owl:Restriction> > > </rdfs:subClassOf> > > </owl:Class> > > </rdf:RDF> > > > The XML Schema's "Person" definition specifies a choice between a > > "Male" and "Female". For an XML instance document to validate against > > this schema, a "Person" element must contain either a "Male" element > > or a "Female" element, but not both. > > > It appears the TBC-generated ontology's "Person" class does not > > capture this. According tohttp://www.w3.org/TR/owl-guide/, "class > > definitions have multiple subparts that are implicitly conjoined, and > > the following example is provided. > > > <owl:Class rdf:ID="Wine"> > > <rdfs:subClassOf rdf:resource="&food;PotableLiquid"/> > > <rdfs:subClassOf> > > <owl:Restriction> > > <owl:onProperty rdf:resource="#madeFromGrape"/> > > <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</ > > owl:minCardinality> > > </owl:Restriction> > > </rdfs:subClassOf> > > ... > > </owl:Class> > > > I interpret "implicitly conjoined" as a union set operation. It my > > interprepation is accurate, then the preceding "Person" class allows a > > Person individual to contain both Male and Female individuals on its > > "hasMale" and "hasFemale" properties, respectively, which clearly > > violates the intent of the "Person" XML Schema definition. > > > Is my assessment correct? If so, how can one best semantically > > represent an XML Schema choice compositor within an OWL-DL ontology? > > > Thank you. > > > Regards, > > > Anthony- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TopBraid Composer Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/topbraid-composer-users?hl=en -~----------~----~----~----~------~----~------~--~---
