These days I’m trying to face one of my unresolved matters: having a fine-grained look at semantic linguistic models. Of course it starts with the W3C Community Group Report Ontolex, and as I go step by step, I focus on the basic module Ontology-lexicon interface (ontolex). All quotes in this text are taken from https://www.w3.org/2016/05/ontolex.
After reading the detailed documentation, including descriptions, examples an diagrams, provided by the community group, I usually try to understand the model in my own way looking at the ontology code. For doing so, I reproduce the ontology code retrieved by the URI http://www.w3.org/ns/lemon/ontolex# on the 25th of March, 2018, by creating a diagram following an adapted UML_Ont profile for ontologies. In this post, I’ll try to show the benefits of combining both approaches, that is, understanding the model from the documentation and from the code, double checking definitions and implementation. It should be mentioned that this analysis is by no mean intended to be exhaustive.
It should be mentioned that for those domains and ranges not defined in the ontology I display them as owl:Thing, so that an instance of any class could be placed. I only found out during this analysis that it is not always the case, as in this particular model some properties aim at linking to classes instead of instances. Anyway, it was interesting taking this decision to analyze the model to see some differences in the properties definition.
The resulting diagram is:
While creating the diagram I observed that the inverse properties ontolex:isLexicalizedSenseOf and ontolex:lexicalizedSense are actually defined with the same domain and range. It seems that ontolex:isLexicalizedSenseOf domain and range should be interchanged.
For the case of the property ontolex:isDenotedBy, as I establish empty domains to owl:Thing, its domain does not match, in the diagram, with its inverse range, which is set at rdfs:Resource. Even though it is not a critical issue and there are examples of use in the documentation, it might be a good idea to clarify that, also in the code. According to the documentation provided for ontolex, the expected domain would be rdfs:Resource due to the following explanation:
Note that the target of a denotation does not need to be an individual in the ontology but may also refer to a class, property or datatype property defined by the ontology.
However, one should keep in mind that using, for example, ontology classes as objects of a materialized property, could make the model run into OWL Full, as a URI would act as individual and class at the same time.
Another issue with the domains appears in the property chain: ontolex:sense o ontolex:reference -> ontolex:denotes, as one might expect that the range of the first property is compatible with the domain of the second one in the antecedent. Such a chain is supposed to be used as documented in section 3.4. However, looking at the diagram extracted from the ontology the domain of the ontolex:reference does not quite match the expected from the examples and core lemon ontolex diagram provided. According to the owl code the domain of ontolex:reference is the union of ontolex:LexicalEntry and synsem:OntoMap. In this case, ontolex:LexicalEntry should be replaces in the domain by ontolex:LexicalSense according to the HTML documentation:
Reference (Object Property)
Domain: LexicalSense or synsem:OntoMap
Having seen this issues with the domains and ranges I realized I didn’t check what OOPS! could spot (how odd..). Apart from OOPS!’s usual complaints, there is one interesting issue. It is about “P40. Namespace hijacking” (powered by Triple-Checker). In this case the elements in which the pitfall is detected are:
The third case seems to be a false positive, even though TripleChecker finds a difference of 1 character, I can’t actually find it.
Regarding this issue, it is worth noting the following line of the RDF/XML code:
- Line 620: <owl:Class rdf:about=”&rdf;Resource”/>
The element “Resource” here is defined in the rdf namespace instead of rdfs where it is originally defined as “rdfs:Resource a rdfs:Class“.
Finally, from a user point of view I usually find helpful that the elements intended to be used in the model coming from other vocabularies, for example skos, are included also in the code and the documentation in a consistent way. I mean, skos:definition appears in the HTML documentation but not in the owl code, however, skos:Concept and skos:ConceptSchema do appear in the code as subclasses of them are defined. The property skos:definition could also be included, and maybe add a local restriction in the class expected to have such attribute, ontolex:LexicalConcept, according to the documentation:
Acknowledgments: I’d like to thank Julia Bosque Gil first for all the help with linguistic models and for the comments about this post.