Modelling OWL datatype property restrictions with a list of values

Question

I have class called ResponseInformation that a has a datatype property called hasResponseType, which must have only the following string values: "Accept", "Decline" and "Provisional".

I understand that I can model this as a set of individuals of a class called ResponseType which are then called accept, decline, and provisional respectively, and an owl:oneOf axiom stating that the class ResponseType is equivalent to exactly "one of" this set of instances. However, I came to realise that OWL 2 supports lists of values as ranges for datatype properties. For example, I can specify the following as the range of my hasResponseType property in Protege: {"Accept" , "Decline" , "Provisional"}

This seems like the easier of the two options, as it does not involve creating extra classes, individuals etc. I was wondering about the potential tradeoffs if I take the second option, i.e. is there any other advantage, or disadvantage other than the convenience?

Roby

Answer 1

I think that Antoine Zimmermann's answer covers how you can do this fairly well. I do agree that effort required to implement the two approaches is similar. I expect, though I haven't tested this, that some types of reasoning will be more efficient on the datatype option, since I expect that typed literals can be compared for equality and inequality much faster than individuals can be.

However, I think that I'd still suggest taking the enumerated individuals (so that hasResponseType is an object property) approach for at least two reasons:

1. As Atoine's answer points out, it is somewhat dubious that the response type is actually a character string. Instead, it seems like the response type would have a label (or multiple labels, e.g., in different languages) that's a character string.

2. (This is my primary point.) If you want to say anything about response types, they need to be individuals. For instance, when response types are individuals, you can give them additional types, e.g.,

   Accept a GuaranteedResponse
   Decline a not GuaranteedResponse
   Provisional a not GuaranteedResponse
   

   and then you could ask, for instance, how many not GuaranteedRepsonses a given poller collected. You could also associate a code with each response type, e.g.,

   Accept hasCode "x789"
   Decline hasCode "x234"
   Provisional hasCode "x900"
   

   and then pass this on to the responses:

   hasResponseCode subPropertyOf hasResponseType o hasCode
   

   You won't be able to do this if your ResponseTypes are literals, because literals can't be the subject of statements.

Gredel

Answer 2

This second option is not particularly simpler or easier. In one case, you need an extra class and 3 individuals; in the other case, you need an extra datatype and 3 values. I don't see a significant difference in terms of effort of ontology development. In terms of reasoning, it depends on the implementation, but I'm not sure reasoners are usually better at handling enumerated datatypes rather than enumerated classes.

Besides, there is a conceptual problem in saying that a "response type" is a sequence of character. Especially, thinking of a "decline" response type, which would be "refuser" in French, I would find it hard to argue that "refuser" is a character string that starts with a capital "D"! With individuals, I can indicate different names for different languages and provide a description of them. Besides, why must response types be strictly limited to only these three types? I would rather model this as follows:

:ResponseType  a  owl:Class .
:accept  a  :ResponseType;
    rdfs:label  "Accept"@en, "Accepter"@fr;
    rdfs:comment "This response type indicates that the request is accepted."@en,
                 "Ce type de réponse indique que la requête est acceptée."@fr .
:decline  a  :ResponseType .
    rdfs:label  "Decline"@en, "Refuser"@fr;
    rdfs:comment  "..."@en, "..."@fr .
:provisional  a  :ResponseType .
    rdfs:label  "Provisional"@en, "Provisoire"@fr;
    rdfs:comment  "..."@en, "..."@fr .
[]  a  owl:AllDifferent;
    owl:members  ( :accept :decline :provisional ) .
:hasResponseType  a  owl:ObjectProperty;
    rdfs:range  :ResponseType .

If you really want Accept, Deny and Provisional to be the only possible response types, you can add:

:ResponseType  rdfs:subClassOf  [
    a  owl:Class;
    owl:oneOf  ( :accept :decline :provisional )
] .

If you want to be more concise, you can also write:

:accept  a  owl:Thing .
:decline  a  owl:Thing .
:provisional  a  owl:Thing .
:hasResponseType  a  owl:ObjectProperty;
    rdfs:range  [
        a  owl:Class;
        owl:oneOf  ( :accept :decline :provisional )
    ] .

The alternative that you were looking for can be expressed like this:

:hasResponseType  a  owl:DatatypeProperty;
    rdfs:range  [
        a  rdfs:Datatype;
        owl:oneOf  ( "Accept" "Decline" "Provisional" )
    ] .

Yes, the Turtle serialisation has 3 less lines, but it does not mean that with an efficient user interface it would be much faster.

Leclerc

I think one advantage in using an enumerated datatype is that it's much easier to tell, just by looking, whether two literals are distinct values or not. It's easy enough to state in OWL that individuals are different from each other, using that information still requires an appeal that must consider that information. Knowing that "string1"^^xsd:string and "string2"^^xsd:string are different is immediate, and doesn't depend at all what axioms are in the ontology. – Gredel

And yes, I do realize that some datatypes have multiple lexical forms mapped to the same element of the datatype (e.g., "TRUE"^^xsd:boolean and "1"^^xsd:boolean might both represent the abstract value true). So it's not as simple as comparing the lexical forms, but once a literal has been parsed into its canonical form, comparison is very quick. – Gredel