Modelling OWL datatype property restrictions with a list of values

后端 未结 2 1939
夕颜
夕颜 2020-12-18 16:35

I have class called ResponseInformation that a has a datatype property called hasResponseType, which must have only the following string values: \"Accept\", \"Decl

相关标签:
2条回答
  • 2020-12-18 17:21

    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.

    0 讨论(0)
  • 2020-12-18 17:37

    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.

    0 讨论(0)
提交回复
热议问题