LexGrid 2008 and OWL

General notes:

• We agreed that a OWL-LexGrid-OWL round-trip is not required for the BioPortal purposes. This decision simplifies some of the handling of imported ontologies.
• We understand that while the model seems to account for many OWL features, some critical ones have not been validated yet. We see validation as using either the API or the UI (not necessarily both) to access the stored information. Some of the information has not been stored at all yet. We all agree that validation through the API access (and, preferably, UI) of all features of the model is required to ensure that the information is represented faithfully.

-- Tredmond 19:12, 3 December 2008 (UTC) I think that one of the issues with this document is that it lacks a statement of purpose. I have heard rumors that the lexgrid owl api is a general purpose owl api like the owlapi. These rumors are suspect and probably have an unacceptably long trail of gossip. Alternatively, parts of this document suggest that all that is needed here is to meet some set of requirements for the Bioportal. These two extremes are very different things.

If the lexgrid api is intended as a general purpose owl api, then I have not yet seen a document that makes me believe that it will be done correctly. Much of what I see on this wiki is suspicious. To really argue that we have a general purpose api, I would want to see some sort of mapping from the owl 1.0 or 2.0 specifications to the implementation. The owl api was a great example of this. The owl 2.0 specifications have changed considerably but the old specification is still here so this can still be verified. Many important java classes map in an obvious way to the specification. For most of the left hand sides of productions in the OWL 2.0 specification, there was an owl api java class that has corresponding characteristics. In contrast, the Protege 3 owl api shows some of the risks incurred when an owl api is built without a clear mapping to the specification.

At the other extreme, if the lexgrid api is just supposed to be a utility library that provides some useful functionality for Bioportal and other applications, then the bar is set at a very different level. The important thing to determine in this case would be exactly what functionality is supposed to be supported and how this support will be achieved. A clear specification of what the lexgrid library does would be a valuable step in determining that it achieves its functionality.

-- Tredmond 19:12, 3 December 2008 (UTC) End Comment

-- Tredmond 23:06, 5 December 2008 (UTC) Various people have responded that the lexgrid owl api is not a general purpose owl api like the owlapi. However at the conference call, there was discussion indicating that the lexgrid api is intended to capture all the different parts of the owl syntax. The line was essentially drawn at inference as being something that would not be included. With a disciplined approach based on the owl specifications this should be very possible but it will otherwise be quite difficult to get right.

Major features that the model does not seem to handle yet

Namespaces versus imported (composite) ontologies

This problem is probably the most serious one and the hardest to address in the current model and has two parts: The model does not make a distinction between a namespace as a unit and an ontology as a unit. In reality, there is no one-to-one correspondence between an ontology and a namespace. The model assumes a uniqueness of a namespace prefix throughout all the coding schemes and uses the namespace prefix as a coding scheme id. This approach will fail in BioPortal, as many ontologies import the same ontologies (but, perhaps, different versions of them) with the same namespace prefix. For example, BIRNLex and OBI import some of the same ontologies. It seems that the current model will not be able to handle such case. Example: ontology 1:

 ...
 xml:p1="http://www.owl-ontologies.com/Ontology1222730448.owl">
 <owl:Ontology rdf:about="http://www.owl-ontologies.com/ontology1.owl">
   <owl:imports rdf:resource="http://www.owl-ontologies.com/Ontology1222730448.owl"/>
 </owl:Ontology>
 ...

ontology 2:

 ...
 xml:p1="http://www.owl-ontologies.com/Ontologyabc.owl">
 <owl:Ontology rdf:about="http://www.owl-ontologies.com/ontology2.owl">
   <owl:imports rdf:resource="http://www.owl-ontologies.com/Ontologyabc.owl"/>
 </owl:Ontology>
 ...

Or the same example without the imports

--Hsolbrig 09:38, 15 October 2008 (PDT)

Namespace as a unit and ontology as a unit

Namespaces from the OWL 1.1 perspective

The OWL Ontology model (at least 1.1) has at least three namespaces associated with a given class, property or instance:

1. The namespace of the entry identifier itself. The only official requirement for this is that it has to be a URI. Examples of valid URI's include:
   • http://www.w3.org/TR/2003/PR-owl-guide-20031209/food#PotableLiquid - this is the sort of URI that is typically used by the W3C. It just happens that this is also a URL that resolves to the declaration of an entity that is defined within a resource that happens to be named http://www.w3.org/TR/2003/PR-owl-guide-20031209/food#.
   • http://www.w3.org/TR/2003/PR-owl-guide-20031209/food#HotDish - this looks like a W3C type URI, but while it happens to resolve to a URL, this URL is not the resource that defines "HotDish". Its definition can be found in http://wiktology.com/rdf/2008/PR-loon-guide/MinnesotaFood# and http://wiktology.com/rdf/2008/PR-loon-guide/AugmentedFood#).
   • urn:oid:2.16.840.1.113883.6.99:17 - This is also a valid URI, but is opaque. While it may be possible to infer that "17" is a resource that is defined by an entity named "2.16.840.1.113883.6.99", this is a bit of a stretch.
   • urn:dce:f140ae9d-67c1-4f19-86a1-39837d79a050 - This is also a valid URI, which is completely opaque.
2. The ontology(s) that make assertions about the resource.
   • Both http://www.w3.org/2000/01/rdf-schema# and http://www.w3.org/2002/07/owl# make assertions about http://www.w3.org/2000/01/rdf-schema#label
   • Both http://wiktology.com/rdf/2008/PR-loon-guide/MinnesotaFood# and http://wiktology.com/rdf/2008/PR-loon-guide/AugmentedFood# make assertions about http://www.w3.org/TR/2003/PR-owl-guide-20031209/food#HotDish
3. The ontology(s) that import the resource - note that "import" is orthogonal to (2) above. What a given ontology imports and what resources it makes assertions about do not necessarily have to be related.

Basic requirements

We can tease at least three requirements out of these namespaces:

1. Requirement 1: - a resource URI must be independent of the ontology(s) making assertions about the resource.
2. Requirement 2: - we need to be able to list all of the axioms that are known (about a given resource) from the perspective of a given ontology.
3. Requirement 3: - we need to be able to list all of the axioms that are directly asserted (about a given resource) by a given ontology.

LexGrid importing today

The LexGrid model was originally designed with the notion that the lexical characteristics of a class, property or individual would be asserted within the same resource that provides the namespace for the resource itself. The model did, however, allow a resource to make both ObjectProperty and DataProperty assertions about any resource, independent of where it was declared.

The latest LexGrid model added the notion of Entity.codingSchemeId, which partially addresses requirement 1 above. It still assumes that the URI can be partitioned into a namespace and an entry code, which may not always be the case. We believe, however, that completely opaque resource identifier is something that we may declare to be out of scope.

The treatment of the semantics of CodingScheme inclusion is inconsistent, however.

At the moment, there are two different LexGrid Importers - an official one built into the LexBIG suite and second one developed by Apelon for the UN Food and Agriculture Organization (FAO). The LexBIG importer currently renders every assertion and resource in a given ontology as a part of that ontology in a single coding scheme, which addresses Requirements 1 and 2, but ignores Requirement 3.

The importer that was written by Apelon only renders the assertions that are directly made about any resource, which addresses Requirement 3, but leaves Requirement 2 (partially) unaddressed.

Namespace prefix issues

LexGrid supports a local name to URI mapping mechanism that is similar to that used in XML. Using the example above, the resulting codingScheme declaration would be:

<codingSchemes dc="codingSchemes">
                <codingScheme  codingScheme="ontology1" formalName="Ontology One" registeredName="http://www.owl-ontologies.com/ontology1.owl" defaultLanguage="en" representsVersion="UNK">
                <localName>ontology1</localName>
                <mappings dc="mappings">
                        <supportedCodingScheme isImported="true" localId="p1" urn="http://www.owl-ontologies.com/Ontology1222730448.owl"/>
                        <supportedCodingScheme isImported="false" localId="ontology1" urn="http://www.owl-ontologies.com/ontology1.owl"/>
                </mappings>
        </codingScheme>
        <codingScheme  codingScheme="ontology2" formalName="Ontology Two" registeredName="http://www.owl-ontologies.com/ontology2.owl" defaultLanguage="en" representsVersion="UNK">
                <localName>ontology2</localName>
                <mappings dc="mappings">
                        <supportedCodingScheme isImported="true" localId="p1" urn="http://www.owl-ontologies.com/Ontologyabc.owl"/>
                        <supportedCodingScheme isImported="false" localId="ontology2" urn="http://www.owl-ontologies.com/ontology2.owl"/>
                </mappings>
        </codingScheme>
</codingSchemes>

The local identifiers only apply within the scope of the containing coding scheme. The identifier, "p1", has no significance outside of the scope of the containing coding scheme, and needs to be translated into the corresponding URI for external reference. The same approach applies to all local identifiers as well. As an example:

  <codingScheme  codingScheme="ontology1" formalName="Ontology One" registeredName="http://www.owl-ontologies.com/ontology1.owl" defaultLanguage="en" representsVersion="UNK">
                <localName>ontology1</localName>
                <mappings dc="mappings">
                        <supportedLanguage localId="en" urn="urn:oid:2.16.840.1.113883.6.84:en"/>
                </mappings>
        </codingScheme>
        <codingScheme  codingScheme="ontology2" formalName="Ontology Two" registeredName="http://www.owl-ontologies.com/ontology2.owl" defaultLanguage="en-US" representsVersion="UNK">
                <localName>ontology2</localName>
                <mappings dc="mappings">
                        <supportedLanguage localId="en-US" urn="urn:oid:2.16.840.1.113883.6.84:en"/>
                        <supportedLanguage localId="eng" urn="urn:oid:2.16.840.1.113883.6.84:en"/>
                </mappings>
        </codingScheme>

ontology1 uses "en" to identify the English language, as identified by IETF 1176. ontology2 uses both "en-US" and "eng" to reference the same thing.

There are a couple of specific issues that need to be addressed when it comes to coding scheme inclusion:

1. Two or more ontologies are imported and each ontology refers to the same URI with a different local name.
2. Two or more ontologies are imported and each ontology refers to a different URI with the same local name.

Same URI, different local name

Take, as an example, http://wiktology.com/rdf/2008/PR-loon-guide/BadFood#, which references the Food Ontology as "feed", and http://wiktology.com/rdf/2008/PR-loon-guide/GoodFood#, which references the same ontology as "fud". A question arises about how these resources should be referenced when they are imported by a third ontology (e.g. http://wiktology.com/rdf/2008/PR-loon-guide/AllFood#).

As near as we can determine, the current version of Protege 4 (Version 4.0 Build 64) doesn't use local identifiers within the editor itself. Internally, local identifiers aren't used, and all references to classes, individuals and axioms are constructed in terms of the URI itself. The Ontology Imports tab appears to use the local identifier from the source ontology. We haven't determined what it does if there isn't a local name in the source. The RDF/XML Rendering tab uses the local name assigned to the resource in the immediately containing ontology.

The equivalent LexGrid rendering *should* follow the same pattern as above, although this still needs to be verified.

Same local name, different URI

The same approach as above, except that http://wiktology.com/rdf/2008/PR-loon-guide/BadBeer# uses the local name "thefood" to refer to http://wiktology.com/rdf/2008/PR-loon-guide/BadFood#, and http://wiktology.com/rdf/2008/PR-loon-guide/GoodBeer# uses the local name "thefood" to refer to http://wiktology.com/rdf/2008/PR-loon-guide/GoodFood#. The results are are the same as above - Protege 4 appears to use the URN internally and resolves the local name when producing rendering.

The equivalent LexGrid rendering *should* follow the same pattern as above, although this still needs to be verified.

Note: We attempted to read the various "loon" files above with Protege 3.3.1, but weren't able to get anything useful to happen.

The equivalent LexGrid rendering of these examples should be:

-- Tredmond 00:20, 6 December 2008 (UTC) In the owl to lexgrid spreadsheet (which may be an obsolete document?), it maps an owl ontology to a coding scheme. The examples above make the coding scheme look more like a set of namespace declarations. Following the owl specifications an ontology document consists of

• a set of name space declarations (represented in lexgrid by the coding scheme above?) and
• an ontology

The ontology consists of

• the ontology declarations
• the import statements
• the ontology axioms

If the goal is to capture all of the owl syntax, then I would say that the above addresses the idea that there will be many coding schemes depending on the ontology document. But it does not address the core issues of representing ontologies which are largely represented by sets of axioms. If we can capture this, then we can represent the notion that a entity definition is found in a particular ontology from the import closure because presumably a definition will correspond to a particular type of axiom.

Inheritance

The issue is not so much with the model but with the need to develop an API that handles inheritance. Currently, the LexGrid API cannot provide any inherited properties or restrictions for a class. There are two possible approaches:

• have LexGrid pre-compute all the inheritance relationships at loading time and store them;
• find the inherited relationships on the fly, when returning informaiton about a class through the LexGrid API.

The first option is likely to increase the required disk space by an order of magnitude (from our experience with NCIT), but will allow using Protege to determine the inheritance relationships. The second option will require non-trivial processing on the API side, as our experience with Protege shows. Determining all the inheritance correctly is harder than it seems. Note that we need inheritance of restrictions, as well as properties for which a class is a domain (see the next item)

--Hsolbrig 09:43, 15 October 2008 (PDT) An additional issue is determining which classification algorithm to use. Not only are there multiple possibilities within the OWL-DL space, but LexGrid can also represent things like the UMLS Semantic Net, which includes "blocking" and other entertaining features. That said, there is an issue that needs to be resolved if the pre-classified approach is to be taken - we need to know which axioms were asserted and which were inferred. This is important both from a browsing and editing perspective as well as necessary for export. The existing OWL specification has no way to differentiate this. Perhaps it would be worthwhile to provide some sort of classifier plug-in that could be invoked at load-time to address this problem.

Properties with no domains and ranges

The LexGrid/OWL specification says:

• (OWLObjectProperty) "An association between two classes (hasDomain, hasRange)."
• (OWLDatatypeProperty) "An association between one class (domain) and one association (hasDomain and hasDataProperty). The conceptProperty defines the range."

However, both datatype properties and object properties can be defined without any domains and ranges (and often are)

-- Tredmond 00:29, 6 December 2008 (UTC) None of the comments here address the issue that the above mapping from owl to lexgrid appears to be simply wrong. I can't find anything in the owl syntax document that would suggest that such a representation of an owl object property can be faithful. This should either be disavowed or explained.

--Hsolbrig 09:46, 15 October 2008 (PDT) The existence of domains and ranges or data properties are not a requirement for determining whether a Property is an ObjectProperty or DatatypeProperty - the description in the mapping spreadsheet was misleading.

--Natasha Noy The question here was whether an association can exit without any source and target

--Jpathak 15:20, 16 October 2008 (CDT) Absolutely, and here is an example where both the domain and range of the property hasIngredient is empty:

<owl:ObjectProperty rdf:ID="hasIngredient">
    <rdfs:comment xml:lang="en">NB Transitive - the ingredients of ingredients are ingredients of the whole</rdfs:comment>
    <owl:inverseOf>
      <owl:ObjectProperty rdf:about="#isIngredientOf"/>
    </owl:inverseOf>
    <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#TransitiveProperty"/>
</owl:ObjectProperty>

<lgRel:association codingSchemeId="rdfs" id="hasDomain" forwardName="hasDomain" isReflexive="false" isSymmetric="false" isTransitive="true">
  <lgRel:sourceEntity sourceCodingScheme="pizza" sourceEntityType="association" sourceId="hasIngredient">
        <lgRel:targetEntity targetEntityType="concept" targetId=""/>
  </lgRel:sourceEntity>
</lgRel:association>

<lgRel:association codingSchemeId="rdfs" id="hasRange" forwardName="hasRange" isReflexive="false" isSymmetric="false" isTransitive="false">
  <lgRel:sourceEntity sourceCodingScheme="pizza" sourceEntityType="association" sourceId="hasIngredient">
        <lgRel:targetEntity targetEntityType="concept" targetId=""/>
   </lgRel:sourceEntity>
</lgRel:Association>

Multiple domains and ranges

It was not clear from our discussion if the model can handle multiple domains and ranges. Usually the requiried semantics is that of a union. Suppose a property P has two domains, A and B, and two ranges, C and D. When rendering details for the class A, BioPortal will need to display all the properties where A is in the domain, and show all the ranges for those properties. So, in this case, when asked for A's properties, we would expect to get the property P, with two ranges, C and D. Note, that we would also want to get that for any subclass of A (see the inheritance point above).

--Hsolbrig 09:47, 15 October 2008 (PDT) To the best of our knowledge, multiple domains and ranges work correctly. LexGrid doesn't add any semantics beyond what is expressed in the OWL itself. We will provide an example here in a few days.

--Jpathak 08:36, 16 October 2008 (CDT) Here is a small example which has been adopted from the Pizza ontology ([1]) by introducing a new class Other_Spiciness and adding it to the domain of the object property hasSpiciness. Here is a snippet from the OWL rendering:

<owl:Class rdf:ID="Other_Spiciness">
    <owl:equivalentClass>
      <owl:Class>
        <owl:unionOf rdf:parseType="Collection">
          <owl:Class rdf:ID="Indian"/>
          <owl:Class rdf:ID="Mexican"/>
          <owl:Class rdf:ID="Thai"/>
       </owl:unionOf>
      </owl:Class>
    </owl:equivalentClass>
    <rdfs:subClassOf>
      <owl:Class rdf:about="#ValuePartition"/>
    </rdfs:subClassOf>
</owl:Class>

<owl:ObjectProperty rdf:about="#hasSpiciness">
    <rdfs:comment xml:lang="en">A property created to be used with the ValuePartition - Spiciness.</rdfs:comment>
    <rdfs:range>
      <owl:Class>
        <owl:unionOf rdf:parseType="Collection">
          <owl:Class rdf:about="#Spiciness"/>
          <owl:Class rdf:about="#Other_Spiciness"/>
        </owl:unionOf>
      </owl:Class>
    </rdfs:range>
    <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#FunctionalProperty"/>
</owl:ObjectProperty>

Then, Other_Spiciness, Mexican, Indian etc. become concepts in our codingScheme, and the domain and range of the property hasSpiciness is represented via the associations hasDomain and hasRange, respectively, as follows in LexGrid:

<lgRel:association codingSchemeId="rdfs" id="hasDomain" forwardName="hasDomain" isReflexive="false" isSymmetric="false" isTransitive="true">
   <lgRel:sourceEntity sourceCodingScheme="pizza" sourceEntityType="association" sourceId="hasSpiciness">
        <lgRel:targetEntity targetEntityType="concept" targetId=""/>
   </lgRel:sourceEntity>
</lgRel:association>

<lgRel:association codingSchemeId="rdfs" id="hasRange" forwardName="hasRange" isReflexive="false" isSymmetric="false" isTransitive="false">
   <lgRel:sourceEntity sourceCodingScheme="pizza" sourceEntityType="association" sourceId="hasSpiciness">
        <lgRel:targetEntity targetCodingScheme="pizza" targetEntityType="concept" targetId="Spiciness"/>
        <lgRel:targetEntity targetCodingScheme="pizza" targetEntityType="concept" targetId="Other_Spiciness"/>
   </lgRel:sourceEntity>
</lgRel:association>

Furthermore, if there is an OWL class defined as: OnionTopping that (hasSpiciness some Medium), it will be represented as:

<lgRel:association codingSchemeId="pizza" id="hasSpiciness" forwardName="hasSpiciness" isFunctional="true" isReverseFunctional="false" isSymmetric="false" isTransitive="false">
    <lgRel:sourceEntity sourceCodingScheme="pizza" sourceEntityType="concept" sourceId="OnionTopping">
       <lgRel:targetEntity targetCodingScheme="pizza" targetEntityType="concept" targetId="Medium">
         <lgRel:associationQualification associationQualifier="owl:someValuesFrom"/>
       </lgRel:targetEntity>
    </lgRel:sourceEntity>

  <lgRel:associationProperty propertyId="P0015" propertyName="isDatatypeProperty">
         <lgCommon:text>false</lgCommon:text>
  </lgRel:associationProperty>
  <lgRel:associationProperty propertyId="P0016" propertyName="isObjectProperty">
         <lgCommon:text>true</lgCommon:text>
  </lgRel:associationProperty>
</lgRel:association>

-- Tredmond 21:58, 20 October 2008 (UTC) While this is probably not the most critical section, some of this discussion is confusing. For example there are the following two conflicting quotes: "Usually the requiried semantics is that of a union." and "To the best of our knowledge, multiple domains and ranges work correctly. LexGrid doesn't add any semantics beyond what is expressed in the OWL itself." The examples that follow reinforce the confusion by suggesting that for LexGrid multiple domains are viewed as unions. In owl the assertion that A is a domain for a property p and B is a domain for a property p is semantically equivalent to the assertion that the intersection of A and B is a domain for the property p. Another quote that is confusing is the statement that "Note, that we would also want to get that for any subclass of A (see the inheritance point above).". It is true that this is what Protege 3 does in the properties view but this view is confusing. If A is a domain for the property p and if B is a sub class of A then it cannot be inferred that B is a domain for the property p. So for instance, one might know that Person is a domain for the property isSisterOf. But it would not follow that the subclass Men of Person is a domain for the property isSisterOf. In fact the correct inference goes in the exact opposite direction. If A is a domain for the property p and B is a superclass of A then B is a domain for the property p. In particular owl:Thing is (semantically) a domain for all properties. So at issue here is that the owl domain concept does not operate in the way that users familiar with, say, java object inheritance would expect. A possible point of view is that multiple domains and ranges - in the owl sense - are not supported? I suspect that correct usage of multiple domains and ranges in owl ontologies is not typical. Other options?

Major features in the model that have not been validated yet

1. Instances
2. Subproperties

--Jpathak 10:10, 16 October 2008 (CDT) We address the above items as follows:

• For instances, assume that the class Country in the Pizza ontology has been modified as follows (by adding a new hasShortName datatype property):

<owl:Class rdf:ID="Country">
    <owl:equivalentClass>
      <owl:Class>
        <owl:intersectionOf rdf:parseType="Collection">
          <owl:Class>
            <owl:oneOf rdf:parseType="Collection">
              <Country rdf:ID="America">
                <hasShortName xml:lang="en">USA</hasShortName>
                <hasCapital>
                  <Capital rdf:ID="Washington_DC"/>
                </hasCapital>
              </Country>
              <Country rdf:ID="England">
                <hasShortName xml:lang="en">UK</hasShortName>
                <hasCapital>
                  <Capital rdf:ID="London"/>
                </hasCapital>
              </Country>
              <Country rdf:ID="France">
                <hasShortName xml:lang="en">FR</hasShortName>
                <hasCapital>
                  <Capital rdf:ID="Paris"/>
                </hasCapital>
              </Country>
              <Country rdf:ID="Germany">
                <hasShortName xml:lang="en">GDR</hasShortName>
                <hasCapital>
                  <Capital rdf:ID="Berlin"/>
                </hasCapital>
              </Country>
              <Country rdf:about="#Italy"/>
            </owl:oneOf>
          </owl:Class>
          <owl:Class rdf:about="#DomainConcept"/>
        </owl:intersectionOf>
      </owl:Class>
    </owl:equivalentClass>
    <rdfs:label xml:lang="pt">Pais</rdfs:label>
    <rdfs:comment xml:lang="en">A class that is equivalent to the set of individuals that are described in the enumeration - ie Countries can only be either America, England, France, Germany or Italy and nothing else. Note that these individuals have been asserted to be allDifferent from each other.</rdfs:comment>
</owl:Class>

Then, the information about an individual, such as Germany, will be represented in LexGrid as follows:

<instances dc="instances">
 <lgCon:instance codingSchemeId="pizza" id="Germany">
      <lgCommon:entityDescription>Germany</lgCommon:entityDescription>
      <lgCon:instanceProperty propertyId="P0001" propertyName="isInstanceOf">
        <lgCommon:text>Country</lgCommon:text>
      </lgCon:instanceProperty>
      <lgCon:instanceProperty propertyId="P0002" propertyName="hasShortName">
        <lgCommon:text>GDR</lgCommon:text>
      </lgCon:instanceProperty>
      <lgCon:instanceProperty propertyId="P0003" propertyName="hasCapital">
        <lgCommon:text>Berlin</lgCommon:text>
      </lgCon:instanceProperty>
 </lgCon:instance>
</instances>

• For sub-properties, again lets taken an OWL snippet from the Pizza ontology:

  <owl:ObjectProperty rdf:about="#hasBase">
    <rdfs:range rdf:resource="#PizzaBase"/>
    <rdfs:domain rdf:resource="#Pizza"/>
    <owl:inverseOf>
      <owl:ObjectProperty rdf:ID="isBaseOf"/>
    </owl:inverseOf>
    <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#InverseFunctionalProperty"/>
    <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#FunctionalProperty"/>
    <rdfs:subPropertyOf rdf:resource="#hasIngredient"/>
  </owl:ObjectProperty>

This information about the property hasBase will be represented in LexGrid with the relations container as:

<relations dc="associations">
  <lgRel:association codingSchemeId="rdfs" id="subPropertyOf" forwardName="subPropertyOf" isFunctional="false" isReflexive="true" isSymmetric="false" isTransitive="true">
      <lgRel:sourceEntity sourceCodingScheme="pizza" sourceEntityType="association" sourceId="hasBase">
        <lgRel:targetEntity targetCodingScheme="pizza" targetEntityType="association" targetId="hasIngredient"/>
      </lgRel:sourceEntity>
   </lbRel:association>
   <lgRel:association codingSchemeId="rdfs" id="hasDomain" forwardName="hasDomain" isReflexive="false" isSymmetric="false" isTransitive="true">
      <lgRel:sourceEntity sourceCodingScheme="pizza" sourceEntityType="association" sourceId="hasBase">
        <lgRel:targetEntity targetCodingScheme="pizza" targetEntityType="concept" targetId="Pizza"/>
      </lgRel:sourceEntity>
   </lbRel:association>
   <lgRel:association codingSchemeId="rdfs" id="hasRange" forwardName="hasRange" isReflexive="false" isSymmetric="false" isTransitive="false">
      <lgRel:sourceEntity sourceCodingScheme="pizza" sourceEntityType="association" sourceId="hasBase">
        <lgRel:targetEntity targetCodingScheme="pizza" targetEntityType="concept" targetId="PizzaBase"/>
      </lgRel:sourceEntity>
   </lbRel:association>
    <lgRel:association codingSchemeId="owl" id="inverseOf" forwardName="inverseOf" isFunctional="false" isReflexive="true" isSymmetric="true" isTransitive="true" reverseName="inverseOf">
      <lgRel:sourceEntity sourceCodingScheme="pizza" sourceEntityType="association" sourceId="hasBase">
        <lgRel:targetEntity targetCodingScheme="pizza" targetEntityType="association" targetId="isBaseOf"/>
      </lgRel:sourceEntity>
    </lbRel:association>
</relations>

Note that additional information about hasBase (e.g., it is an InverseFunctionalProperty and a FunctionalProperty) is not displayed above (you can find this information from the XML if you download the ZIP file: [2].)

Major features that may already be in the API or the UI, but we did not validate yet

1. Distinction between annotation properties and restrictions or properties that have a class in the domain (there are different properties at a class and will need to be returned/rendered differently
2. Domains and ranges of properties (in the case where there is one domain and one range)
3. Property values (for datatype properties in particular)

--Hsolbrig 09:50, 15 October 2008 (PDT) Item (1) above is of some concern. What we propose doing is to represent AnnotationProperties as "Properties" and DatatypeProperties as "associations". There are apparently some issues with this, however, when it comes to the API and its rendering. At the moment, we reflect all DatatypeProperties as both, which is not a good idea in the long run.

Features that are missing from the model but that are easy to add

• Distinction between necessary and necessary and sufficient conditions for defined classes (an extra qualifier for the restriction)

--Jpathak 10:36, 16 October 2008 (CDT) I agree.