Proper use of rdfs:subPropertyOf

Question

I would like to represent the following relationships using rdf and rdfs:

"Assessment Technique" (AT) has a property of "Assessment Characteristics" (AC). In a database, this would be represented by there being two tables, one for AT and the other AC linked with a foreign key in AC pointing back to the primary key in AT.

So what I have come up with so far using rdf and rdfs is the following classes that would represent the two tables:

ex:AssessmentTechnique rdfs:label "Assessment Technique" .
ex:AssessmentCharacteristic rdfs:label "Assessment Characteristic" .

My question is about the specific characterstics in the AC table. Can these be - or are they - properly called sub-properties of hasAssessmentCharacteristics? Or should each specific characteristic be its own property? I have tried to create them as sub-properties, but then the range of hasAssessmentCharacteristics is a class and those of sub-properties are usually of type xsd:string or xsd:int, and this goes against the rule that sub-properties have the same domain and range adn the parent property. So the following is incorrect, though it expresses the intent.

ex:hasAssessmentCharacteristics
  rdf:type rdfs:Property;
  rdfs:label "has Assessment Characteristics";
  rdfs:domain ex:AssessmentTechnique;
  rdfs:range ex:AssessmentCharacteristics .

ex:hasNumberOfItems
  rdfs:subPropertyOf ex:hasAssessmentCharacteristics;
  rdfs:label "has Number of Items";
  rdfs:domain ex:AssessmentTechnique;
  rdfs:range xsd:int .

The only other way I have been able to think of doing this is to ignore the fact that each column from the AC table comes from the same table and instead have a series of property assignment statements like this:

ex:hasNumberOfItems
  rdf:type rdfs:Property;
  rdfs:domain ex:AssessmentTechnique;
  rdfs:range xsd:int .    

ex:hasPublicAvailability
  rdf:type rdfs:Property;
  rdfs:domain ex:AssessmentTechnique;
  rdfs:range xsd:string .

ex:hasURL
  rdf:type rdfs:Property;
  rdfs:domain ex:AssessmentTechnique;
  rdfs:range xsd:string .

and so on....

I've see that there are ways to have containers in rdfs but from my reading of the reference material it seems that this pertains to hen houses and the hens contained therein and not a way of containing or collecting different types of characteristics of a hen (to extend the use of the metaphor) to things like

• Anatomy
• Diet
• Behavior
• and so on....

So if I am to create a long list of properties without any "tagging" to keep them organized, I'll do something with comments. But if there is a way of organizing these using rdf or rdfs or owl then I'd appreciate someone pointing me the way.

Paul

Twohanded

Answer 1

My question is about the specific characterstics in the AC table. Can these be - or are they - properly called sub-properties of hasAssessmentCharacteristics? Or should each specific characteristic be its own property?

Without even knowing the specifics of your domain model, the answer lies in the actual meaning of subproperty. A property p is a subproperty of property q exactly when:

        p(x,y) implies q(x,y)

That's how subproperty assertions are used in RDFS inference. If one property is a subproperty of another, then whenever you see a usage of the first, you can infer the other. So, for instance, hasDaughter is a subproperty of hasChild, since we know that if someone has a x as a daughter, then they have x as a child.

It sounds like you're looking to have a toplevel property (names simplified) hasCharacteristic and define some subproperties that specify individual characteristics. There's no problem with that. For instance, we might, in describing a person, do:

:hasCharacteristic a rdfs:Property .

:hasHeightInInches rdfs:subPropertyOf :hasCharacteristics ;
                   rdfs:range xsd:int .

:hasName           rdfs:subPropertyOf :hasCharacteristic ;
                   rdfs:range xsd:string .

You're right about the domains and ranges, though; if the domains or ranges of the subproperties are incompatible, then you need to make sure that you either have a common enough superclasses on the super property, or just don't declare them at all. In the sample above, you could ask for all the values of :hasCharacteristic for a person, and you'd get their name and height in inches,, and there'd be no problem with the fact that you're getting numbers and strings.

Regarding domains and ranges, remember that a property p having domain D simply means that:

        p(x,y) implies D(x)

and having range R means that:

        p(x,y) implies R(y)

One of the consequences of this is that domains and ranges are "inherited" by subproperties. Suppose p is a subproperty of q, and q has domain D. Then from p(x,y), we can infer q(x,y) (since p is a subproperty of q), and then we can infer that D(x) (since D is a domain of q). That means that in my example above, you could declare a common domain on the superproperty:

:hasCharacteristic a rdfs:Property ;
                   rdfs:domain :Person .

:hasHeightInInches rdfs:subPropertyOf :hasCharacteristics ;
                   rdfs:range xsd:int .

:hasName           rdfs:subPropertyOf :hasCharacteristic ;
                   rdfs:range xsd:string .

Now, whenever you see, e.g.,

        hasName(x,y)

you can infer this additional information:

        hasCharacteristic(x,y)
        Person(x)
        xsd:string(y)

Rikki

Answer 2

I have tried to create them as sub-properties, but then the range of hasAssessmentCharacteristics is a class and those of sub-properties are usually of type xsd:string or xsd:int, and this goes against the rule that sub-properties have the same domain and range adn the parent property.

Well then, why not not define the range of hasAssesmentCharacteristics to be a class?

  ex:hasAssessmentCharacteristics
    rdf:type rdfs:Property;
    rdfs:label "has Assessment Characteristics" .

  ex:hasNumberOfItems
    rdfs:subPropertyOf ex:hasAssessmentCharacteristics;
    rdfs:label "has Number of Items";
    rdfs:domain ex:AssessmentTechnique;
    rdfs:range xsd:int .

The above is perfectly fine (and consistent).

The only other way I have been able to think of doing this is to ignore the fact that each column from the AC table comes from the same table and instead have a series of property assignment statements like this:

The thing you are struggling with is actually quite fundamental to the RDF model: unlike in a lot of other modeling paradigms, properties are first-class citizens. A property is a "thing" in its own right, and not just an attribute of a class (which can not exist without the class) or a column of a table (which can not exist without the table). So it is to be expected, to a degree, that the definitions of properties are less tightly connected to the classes.

That being said, your idea to use the rdfs:subPropertyOf relation to bundle several properties together is absolutely fine. The trick is to just be very reticent about defining domains and ranges at a high level.

By the way, if you move from RDFS to a more expressive language like OWL, you have a little more control over this type of thing. OWL allows you to specify class-specific restrictions of domains and ranges (though you still can not completely "override" domains and ranges of parent properties). Whether moving to OWL is worth it (one of the downsides is having to deal with a more complex language and data model) depends on what you actually intend to use the model for.

Roy