Data properties are a frequently used construct in OWL ontologies. As the name suggests, they are however biased towards the world of 'data' rather than that of ontologically grounded entities. On the other hand, we hypothesize that many data properties bear inherent meaning that can be captured through simple ontological categories (such as objects, relationships or events). We formulated intuitive categories of data property 'background' categories, only indirectly connected to the 'surface' categories (i.e., to data property range options) and performed an annotation experiment of a sample of data properties from diferent ontologies according to this system of categories. The results indicate that the ontological nature of most data properties can be characterized with reasonable human efort, opening the question of possible automated analysis in the future.
The abundance of data properties is an aspect that often distinguishes semantic web ontologies (foremost, OWL) from philosophically grounded reference ontologies as well as from theories expressed primarily in formal logic. The values of data properties are literals, which belong (either explicitly, for typed literals, or implicitly, for simple literals) to data types. While custom data types can be defined in OWL, the range of a vast majority of data properties in ontologies is one of pre-defined data types, corresponding to what is commonly used in programming languages: xsd:string, xsd:integer, xsd:float, xsd:boolean, xsd:dateTime, or the like.
Ontology-based knowledge graphs are however not of the same nature as procedural program code. Their statements are meant to be declarative facts aiming to describe situations occurring in the world. We hypothesize that this applies not only to object property assertions but also to data property assertions, although a bit less obviously and perhaps with exceptions. To say, the values of data properties, as well as these properties themselves, may refer to “background” ontological entities that can be (were this the modeler’s choice) equally expressed by diferent means, through classes and individuals interconnected by object properties. For example, if a string-range data property refers to a country code (e.g., someprefix:countryOfBirth), it actually expresses the relationship of an entity (here, a person) to a country. Similarly, a boolean property may serve for defining a distinction that could equally be modelled as a class (say, a boolean data property someprefix:retired may be replaced with a class someprefix:RetiredPerson). Note that the background semantics does not unambiguously follow from the data type. In particular, a string may also refer to other things than ‘real objects’. Similarly, an integer may express, for example, a mere truncated quantitative value (e.g., the someprefix:maxSpeed of a car) or the count of links to objects of some kind (e.g., someprefix:numberOfDoors of a car).
Successful capturing of the ontological background of data properties may serve various practical purposes. Feedback on implicit ‘background’ structures may lead to suggestions for the ontology designers/maintainers to make these structures explicit via a reengineering process, and thus increase https://nb.vse.cz/~svatek/ (V. Svátek); https://nb.vse.cz/~svabo/ (O. Zamazal)
CEUR
ceur-ws.org the expressiveness and/or readability of the knowledge graphs for particular purposes. It may also be supportive in ontology reuse and ontology alignment.
We are unaware of any study focusing on the problem of this ‘background’ meaning of data properties
in OWL. Empirical studies on OWL ontology collections [
Our study follows up with earlier works on analyzing the ontological background of OWL ontologies.
Diferent systems of foundational distinctions were applied for this purpose: OntoClean with its rigidity,
identity and unity [
In our current research, we decided to essentially reuse the PURO distinctions; they are centered around
a similar, simple meta-model system as that of OWL (PURO objects, types, relationships and valuations
resemble OWL individuals, classes, object properties and data properties), thus instructively manifesting
the divergence between the surface and ontological view. However, compared to the earlier works [
The initial version of categories considered did not rely upon any empirical study, but merely upon the accumulated experience of the authors from ontology engineering projects. In this initial version, 10 categories were suggested (name, identifier, object, type, message, quality, quantitative value, count, date/time, existentially quantified relationship). The categories were (non-uniquely) grouped based on clusters of built-in XSD or RDF data types,1 which were, in turn: string (also including, e.g., rdfs:Literal or xsd:language), integer (and its variation, e.g., non-negative integer), non-integer numerical (float, double, decimal), date/time (again, all variations of temporal types) and boolean. • For a string property: – Name: the property provides a human-readable name for the given instance of the domain2 class. – Id: the property provides an identifier for the given instance of the domain class, for example, a DOI for a publication, or an ORCID for a researcher. – Obj: the string value of the property represents some particular object to which the for the given instance of the domain class is connected. – Tp: the string value of the property refers to a type that is, through the data property, implicitly assigned to the given instance of the domain class (e.g., somePref:Car-1 somePref:carType 1https://www.w3.org/TR/xmlschema-2/#built-in-datatypes 2By ‘domain class’ we understand the class that is assigned to the property through the rdfs:domain predicate. ”SUV”). It is a kind of anti-pattern, as the type would always be better expressed by a class or object property. – Qual: the string value of the property expresses some quality of the given instance of the domain class (e.g., colour “red”), which is neither its type nor another related object, in the usual sense. – Msg: the string value of the property is a human-readable message that either does not reference any domain entities or the ‘background’ of this message is too vague or too complex to be modeled as a structure. • For an integer property: – Quant: the integer value of the property is in fact a (rounded) value of quantitative property of the given instance of the domain class, which is natively non-integer, such as size, maximum speed, length etc. – Count: the property is a counting property, expressing the fact that there is a finite number of objects connected to the given instance of the domain class via the same kind of relationship (e.g., the number of free workplaces available in the given company). • For a non-integer numerical property (only one option anticipated): – Quant: the property value is an (inherently) quantitative, continuous-valued property of the given instance of the domain class (e.g., its weight, length, speed, or the like). • For a date/time property (only one option anticipated): – DTm: the property value represents the date and or time of the given instance of the domain class – meaning that this instance is an event or process (‘perdurant’, in an ontological sense). • For a boolean property: – Tp: the boolean values of the property indicate whether the given instance of the domain class is an instance of a specific type (e.g., somePref:Dataset-1 somePref:isPublic “false”). – Ex: an existentially quantified relationship where the boolean values indicate whether the given instance of the domain class does or does not participate in a particular relationship to another object, whatever the identity/type of this object is (e.g., somePref:Car-1 somePref:hasInsuranceContract “true”, where the contract as such is not assumed to be modeled as an explicit object).
Additionally, an option Chain+<Categ> was anticipated, such that the value of the property would correspond to category <Categ>, however, there would be an (anonymous) intermediate object between the instance of the domain class and the entity referred to by the value.
We randomly selected 30% of ontologies from the Archivo repository (currently containing 1811 ontologies)3 and got 543 ontologies. We ran a simple SPARQL query on this sample to detect all data properties that are in these ontologies and only selected those having both a label (rdfs:label) and a comment (rdfs:comment). From these data properties, we selected at most five for each ontology. This way we got a dataset containing 202 data properties (with their domains and ranges) which were from 64 ontologies (i.e. those containing at least one data property). Finally, to make thorough manual analysis feasible in the limited time, we only picked the first 100 data properties, which corresponded to 30 ontologies.
The annotation campaign was held during August and September 2024 and there were three annotators involved: the paper authors, of which two are ontology engineering experts and one is a PhD student researching in this field, with moderate expertise. The task of all annotators was to select the most adequate ontological category based on simple guidelines;4 the properties were the same for all.
The annotators only examined the labels and comments of the entities that were an explicit part of the pattern, i.e. they did not examine the ontology as a whole.
The annotation of one property took approximately 1.5 minutes on average, ranging from several minutes for tricky cases to tens of seconds for apparently repeated phenomena (however, given the confinement to max. 5 cases from a single ontology, intra-ontology regularities did not have much impact on such repetitiveness).
After the first round, all three annotators agreed in 61 cases, in another 35 cases two annotators agreed, and there were only 4 total disagreements. The breakdown per data type (property range) groups is in Table 1. Note that the table contains one additional row, for the xsd:anyURI type, which had not been considered in the initial category design and could not clearly fit into any of the existing clusters.
This was followed by a workshop, where all three annotators gathered around and discussed the
disagreements and the proposed new categories. Through the workshop, agreement was reached in 99
cases out of 100. Of the 38 cases of posterior agreement:
• For 27, all annotators eventually converged to the verdict of one (or two) of them.
• For 5, it was determined that the guidelines were ambiguous in the sense of allowing to give two
diferent labels to what was the same situation in reality (thus upon the curating the guidelines,
the clash would not exist any longer). This concerned the alternative categorizations of the
value being a related object (Obj) vs. the Id or Name of this related object: the object was always
assumed to be manifested via an Id5 or a name, but some annotators put stress on the fact that
this is a related object and others on the nature of its manifestation (Id or Name).
• For 6, the annotators agreed that based on the available information, it was not possible to tell
whether the values were to be interpreted as objects or their types. For example, in an ontology
about used cars, there was a class “Modification and maintenance” and a datatype property called
“part removed” with its range rdfs:Literal. The question is whether the part removed while
repairing a car is understood as being described at the level of this concrete, physical part (‘left
headlight of car 1234’), or of the type of this part (‘a headlight’). To determine this, we would
have to delve into a concrete knowledge graph, as was previously the case with B-Annot [
Some of the discussions led to creation of new categories that had not been covered by the guidelines. For example, for integer values, we had anticipated two categories: continuous quantity (merely truncated to an integer) and count (as an inherent integer). We however discovered two other, also fairly intuitive, meanings of integer values. First, we discovered a property expressing the rank of the domain object (e.g. wrt. ranking a movie). We decided to have a new category called Rank for such cases, to distinguish this, ordinal, case from both continuous quantities and counts. The rank positions the domain object with respect to other objects and can change even without any alteration of the given object (merely due to alterations of other objects within the ranking). Second, we also discovered a property that expressed the level of an object (which was a gaming character, in this case). While the
level is also ordinal, unlike the rank it depends on the characteristics of the domain objects and is not influenced by the level of other objects. We conceive this category as a special subkind of Type, namely, “Type – ordinal”.
Finally, a substantial revision of the overall system of categories was triggered by the discovery of data properties that, in ontological terms, merely consisted in an ‘arm’ of a relationship (or of a quantitative value assignment). An example is a property ”from” with domain class ”Ownership info”. It seems that the class is actually a reification of the ownership relationship, whose semantics is “An agent owns a vehicle within a certain time period under a certain registration plate.” Under the PURO lenses, stipulating that relationships should be kept unreified as long as possible (thanks to the support of n-ary relationships, of whatever arity and whatever kind of participants, in PURO) ”from” corresponds not to a complete relationship (never mind a chain thereof) but to a subpart of it.
The refined system of 12 ontological categories and 2 ‘special structural cases’, resulting from the annotation campaign and workshop, and planned to be used in the next round of experiments, is then as follows (new/redefined categories in bold; existing ones same as in the initial system from Section 3): • For a string property: Name, Id, Obj, Tp, Qual,6 Msg • For an integer property: Quant, Count, Tp (added here for the case of ordered types), Rank (new category) • For a quantitative or date/time property: Quant, DTm • For a boolean property: Tp, Ex, Match (new category) • For any property, special structural cases: – Chain+<Categ>: the value of the property corresponds to category <Categ>, however, there is an (anonymous) intermediate object between the instance of the domain class and the entity referred to by the value. – Part+<Categ>: the value of the property corresponds to category <Categ>, however, the instance of the domain class can be understood as a reified relationship.
We are presenting a presumably pioneering study focused on the ontological grounding of data properties in OWL ontologies. The presented work is a part of a larger initiative aiming at providing a framework for (semi-)automatically transforming the structure of ontologies, and, accordingly, the knowledge graphs based on them, so that the shape of those graphs would fit a particular application requirements.
As with all such small-scale manual studies, in which new concepts emerge on the fly, a natural next step will be to pick up another random collection of data properties (ideally, from diferent ontologies) and see how well the current version of the category system is applicable and whether it tends to converge or new ontological structures keep emerging.
In longer term, we are aware that analyzing the data properties manually is a relatively demanding exercise. As soon as we gather a decent pool of labeled training examples (for an already consolidated system of categories), we plan to take advantage of deep-learning classifiers , which could be fine-tuned for the given task through the provided examples.7
This work has been supported by the EU’s Horizon Europe grant no. 101058682 (Onto-DESIDE).